Computer method and system for intermediated exchange of commodities

ABSTRACT

In a preferred embodiment, this invention includes software processes distributed on one or more computer systems that exchange messages in order to facilitate an intermediated exchange of financial commodities between a plurality of participants. The messages are exchanged according to a preferred protocol that leads to a satisfactory exchange that meets the objectives of the participants, and that substantially maximizes in a fair manner the total amount of financial commodities exchanged. Optionally, the invention employs heuristic rules in association with the preferred protocol that adapt the protocol to the time and exchange requirements of financial commodities. In other embodiments, this invention is equally applicable to the exchange of any tangible or intangible commodities. In a general embodiment, this invention further includes a preferred message-exchange protocol for the construction of computer programs representing exchange participants and an intermediary. These constructed computer programs exchange messages such that a satisfactory intermediated exchange of commodities is substantially certain to be achieved.

1. FIELD OF THE INVENTION

The field of this invention is computerized information systems directedto commercial applications; in particular computer systems thatfacilitate an automatic exchange of commodities between users of such acomputer system according to the users' goals.

2. BACKGROUND

An intermediated exchange involves negotiated trading between two ormore participants through a third-party, the intermediary. Specifically,in such an intermediated exchange, the participants do not communicatedirectly with each other, but rather through the third-partyintermediary. Examples of items traded include intangibles, such assecurities (stocks, bonds, and options) commodity futures,collateralized mortgage obligations, and pollution rights, as well astangibles, such as copper or soy beans. All such items involved in anintermediated exchange are herein referred to as "commodities." In fact,any item that can be traded is a commodity.

In the case of stocks and options, there are several examples ofintermediaries, which differ depending on the status of the securitiesas listed or as over-the-counter ("OTC") (i.e., unlisted). Listed stocksand options can be traded on securities exchanges, such as the New YorkStock Exchange ("NYSE"), the American Stock Exchange ("AMEX"), and theChicago Board of Options Exchange ("CBOE"). Specialists on the floors ofthese exchanges act as intermediaries for listed securities and,typically, have positions in the securities that they intermediate.Over-the-counter securities can be traded on a computer network, knownas "NASDAQ," which links securities dealers who make markets andtypically maintain positions in certain of these OTC securities. Thesenetworked dealers continually make available on NASDAQ the highest priceat which they will buy a security ("bid price") and the lowest price atwhich they will sell a security ("offer price"). They then act asintermediaries between buyers and sellers of those securities for whichthey make markets. Also, they can trade with each other. Trading on thisnetwork is regulated by the National Association of Securities Dealers("NASD").

Alternately, financial institutions can exchange both listed and OTCsecurities through intermediaries who form the "fourth" market.Fourth-market intermediaries do not maintain security positions;instead, they act only as agents for market participants, whether asbuyers or sellers, maintaining the participant's anonymity andrepresenting the participant's interests. Originally, the fourth marketwas largely a network of securities brokers communicating primarily bytelephone (the "Rolodex" market). Later, Instinet (Reuters, New York,N.Y.) began offering partially automated intermediary services byproviding a computer network through which participants can post theirsecurity trading interests and subsequently can negotiate trades usingstandardized messages made available by the network. More recently,POSIT (ITG, New York, N.Y.) and the Arizona Stock Exchange ("AZX")(Phoenix, Ariz.) began providing more fully automated fourth-marketintermediary services. Instinet, POSIT, and AZX are referred to as"crossing networks" because they provide intermediary services withvarying degrees of computer and communications technology.

In the simple form as currently practiced, a crossing-networkintermediated exchange involves two participants who seek, through acomputerized intermediary, to buy and/or sell a given amount of a givencommodity at a given price. The amount of the commodity is determined bythe network. In more complex forms, an intermediated exchange can bedesirable where multiple participants who seek, through an intermediary,to buy and/or sell multiple commodities, each with a different price.For example, a portfolio manager may seek to execute an optimized seriesof commodity exchanges that are interdependent in the sense that, ifsome exchanges of the series cannot be executed, the portfolio managerwould prefer to withdraw the previous series and submit for execution anew series of exchanges. In this more complex case of multiplecommodities and optimized exchange strategies, the intermediary mayprovide for selecting the actual commodities to be exchanged from a listof possible commodities, as well as for determining the amounts andprices that satisfy the more-complex conditions of the participants. Itis believed that no current network provides such more-complexexchanges. See, e.g., Orford, Trading on the Frontier, Plan Sponsor,October 1996, pp. 18-27.

Most market exchanges of financial commodities involve a specific,single instrument, e.g., "IBM stock," and two counter-parties, one thebuyer and the other the seller. Even the most adaptable crossingnetworks require participants to supply a list of specific commoditiesthey will exchange. But as the size and complexity of commerce andinvestment has grown, participants have become less interested in singlecommodities or lists of specific commodities and have become moreinterested in expressing their exchange goals as portfolios ofcommodities, which are drawn from a general universe of acceptablecommodities and which achieve certain target-risk, return, and exposureprofiles.

In this way, the composition of the associated intermediated exchangewould be less dependent on any single investment or list and moredependent on the aggregate characteristics of all the commoditiescombined. The motivation for this approach is that it permits theparticipant the flexibility to dynamically adapt to market conditionsthat affect the price and availability of individual commodities.Currently, computer systems that support existing markets or crossingnetworks are not able to accommodate the evolving needs of participants,such as investment managers and others, who seek to trade multiplecommodities to achieve general portfolio goals.

In addition, an intermediated exchange meeting those portfolio goals formultiple participants requires a computerized solution of what is knownas a competitive equilibrium problem. See, e.g., Ellickson, 1993,Competitive Equilibrium--Theory and Applications, Cambridge UniversityPress. Currently, no satisfactory solution exists for that problem asapplied to the specific situations of intermediated exchanges.

3. SUMMARY OF THE INVENTION

This invention provides a computer system (a computer-based machineincluding hardware and software) for intermediated exchange that iscapable of facilitating exchanges of multiple commodities for multipleparticipants according to their goals. In the preferred implementationthe computer system of this invention is used for the exchange offinancial commodities according to mean-variance portfolio goals andrelated portfolio constraints. In the preferred implementation,participants can include investors and investing entities. A singleparticipant can appear in an intermediated exchange single or multipletimes. In the latter case, each appearance of a participant can begoverned by the same or different objectives.

The system of the preferred embodiment implements a negotiation protocolthat facilitates the intermediated exchange of commodities between anynumber of participants according to their goals. This negotiationprotocol specifies how to search through possible combinations ofexchanges between participants in order to identify the combination thatbalances the goals of the intermediary with the goals of theparticipants in the exchange. The protocol addresses both thedetermination of which commodities are exchanged among participants andthe amount of each commodity exchanged. It also provides a solution forthe competitive equilibrium problem as it is applied to intermediatedexchanges. A computer program constructed according to this protocol,together with accompanying hardware, permits participants electronicallyand automatically to carry out negotiations for the transfer ofcommodities through an intermediary.

A computer program constructed according to this invention includeselectronic agents ("e-agents"), each of which represents a participant'sexchange goals, and an electronic intermediary, through which thee-agents conduct electronic negotiations leading to an intermediatedexchange. The e-agent program for a participant encodes the exchangegoals and objectives of that participant. Participants can express theirgoals and objectives either (1) as an objective (or utility) functiontogether with optional constraints, or (2) through a set of rules, whichcan be represented in a procedural computer language. Other ways ofexpressing objectives may be supported by a particular embodiment.However expressed, the participants' objectives can be encoded in acomputer program that automatically selects commodities to buy and sellfrom the universe of acceptable commodities on the basis of currentmarket conditions. Systems for intermediated exchange that do not takeinto account participants' general goals can simply be represented asspecial cases of the general e-agents of this invention.

According to this invention, the e-agents negotiate an intermediatedexchange through an intermediary computer program. E-agents, acting inconjunction with the intermediary, process data so as to substantiallymaximize a tradeoff between the amounts exchanged and the fairness ofthe exchange. An intermediary program constructed according to thisinvention acts to substantially maximize the aggregate number of unitsof commodities exchanged in a fair manner that is acceptable to theparticipants.

A preferred implementation of this embodiment represents the e-agentsand the intermediary as one or more software processes residing on oneor more computers. If multiple computers are used, the areinterconnected by a network. These processes carry out the generalnegotiation of this invention by exchanging offer and counter-offermessages over this network and/or using an inter-process messagesmechanism. Preferably, participants access this system for submittingexchange orders and receiving exchange responses over networkconnections. These network connections can be private networks orsuitably secured public networks, such as the Internet. In the preferredembodiment, this invention is adapted to the exchange of financialcommodities, particularly equity securities, but also includingcommodity futures, stock options, collateralized mortgage obligations,and other financial commodities, individually or combined (e.g. equitiesand futures or equity options combined). Equity securities are thosesecurities that represent an ownership interest in property.

Five embodiments of this invention will be described. In a first generalembodiment, this invention comprises a computer system for electronicintermediated exchange of a plurality of commodities among a pluralityof participants. This computer system includes: a plurality of e-agentcomputer programs running on at least one computer, each participantbeing associated with at least one of the e-agent programs, and eache-agent program storing in an associated electronic memory digital datarepresenting commodity exchange objectives of its associatedparticipant; an electronic intermediary program running on at least onecomputer system, the intermediary program storing in an associatedelectronic memory digital data representing commodity exchangeobjectives of the intermediated exchange and exchanging electronic offerand counter-offer messages with the e-agent programs. According to thismessage exchange (i) the e-agent programs receive the electronic offermessages from the intermediary program, generate the electroniccounter-offer messages according to the exchange objectives of theassociated participants, and send the counter-offer messages to theintermediary program, and (ii) the intermediary program receives theelectronic counter-offer messages from the e-agent programs, generatesoffer messages according to the exchange objectives of the intermediatedexchange, and sends the offer messages to the e-agent programs.

This first embodiment can include several more detailed and particularembodiments and aspects, such as the following. In one aspect, theexchange of electronic messages between the intermediary program and thee-agent programs converges to an exchange of commodities that issubstantially satisfactory both to the participants, according to thedigital data representing the commodity exchange objectives of theparticipants, and also to the intermediary program, according to thedigital data representing commodity exchange objectives of theintermediated exchange. Alternatively, the exchange of electronicmessages terminates when the e-agent programs generate counter-offermessages accepting all the amounts of commodities offered in theimmediately preceding offer messages received from the intermediaryprogram.

In another aspect of the first embodiment, the electronic offer messagescontain digital data representing the amounts of the commodities thatthe intermediary program offers to the e-agent programs, and theelectronic counter-offer messages contain digital data representing theamounts of the commodities that the e-agent programs accept from theintermediary program. Further, the e-agent programs and the intermediaryprogram can exchange messages according to sequential rounds of anelectronic negotiation, each round of the negotiation comprising theintermediary program sending electronic offer messages to the e-agentprograms followed by the e-agent programs sending electroniccounter-offer messages to the intermediary program.

In another aspect of the first embodiment, the electronic memoryassociated with the intermediary program stores digital datarepresenting a plurality of current and preceding bounds, each currentbound representing the maximum amount of a particular commodity that canbe offered to a particular e-agent program in a current round of theelectronic negotiation and each preceding bound being a current boundfrom a preceding round of the electronic negotiation. In this case, theintermediary program generates offer messages offering amounts ofcommodities less than or equal to the appropriate one of the currentbounds. Alternatively, the plurality of current bounds depends oncommodity amounts in the intermediary offer messages, the e-agentcounter-offer messages, and the preceding bounds from one or morepreceding rounds of the electronic negotiation, and more particularlyfrom the immediately preceding round of the electronic negotiation.Alternatively, the plurality of current bounds depends on commodityamounts in the e-agent counter-offer messages and on the precedingbounds from the immediately preceding round of the electronicnegotiation.

In another aspect of the first embodiment, the electronic memoryassociated with the intermediary program further stores digital datarepresenting a selected round of the electronic negotiation. For roundsbefore the selected round of negotiation, the plurality of currentbounds are selected to be between commodity amounts in the e-agentcounter-offer messages and the preceding bounds of the immediatelypreceding round of the electronic negotiation. For rounds after theselected round of negotiation, the plurality of current bounds areselected to be equal to preceding e-agent counter-offer messages of theimmediately preceding round of the electronic negotiation.Alternatively, before the selected round of negotiation the plurality ofcurrent bounds are selected to be a weighted average of the commodityamounts in the e-agent counter-offer messages and the preceding boundsof the immediately preceding round of the electronic negotiation.

In another aspect of the first embodiment, the e-agent programs generatecounter-offer messages accepting amounts of commodities that are lessthan or equal to the amounts offered in one or more of the precedingoffer messages received from the intermediary program, and moreparticularly from the immediately preceding offer message.Alternatively, the e-agent programs further send opening messages to theintermediary program before the exchange of offer and counter-offermessages. Each opening message includes digital data representingmaximum amounts of commodities each participant will exchange in theintermediated exchange.

In another aspect of the first embodiment, the commodity exchangeobjectives of the intermediary program comprise that a substantiallymaximized amount of commodities are exchanged in the intermediatedexchange subject to constraints (i) that for each commodity the totalamount sold equals the total amount bought by all the e-agent programs,and (ii) that for each commodity the amount sold or bought by eache-agent program is less than the appropriate one of the bounds.Alternatively, the commodity exchange objectives of the intermediaryprogram further include a measure of the unfairness of the share ofcommodities offered to each e-agent program that is substantiallyminimized. Alternatively, a measure of the fairness can be substantiallymaximized. The measure of unfairness increases as the share ofcommodities offered to each e-agent program differs from a pro-ratashare. Preferably, the measure of unfairness increases as the square ofthe difference of the share of commodities offered to each e-agentprogram differs from a pro-rata share. The pro-rata share for acommodity for an e-agent program can be determined by the ratio of thebounds for that commodity for that e-agent program to the sum of thebounds for that commodity for all the e-agent programs. Alternatively,the measure of unfairness includes a plurality of adjustable factors,each factor associated with an e-agent program and for adjusting therate of increase of the measure of unfairness as the share ofcommodities offered to an e-agent program differs a pro-rata share.

In another aspect of the first embodiment, the intermediary programgenerates the commodity amounts for the offer messages by substantiallymaximizing the value of a utility function of the amounts of commoditiessubject to constraints. The utility function can be a difference of afirst term and a second term, the first term representing the totalamount of all commodities offered to the e-agent programs and the secondterm representing the unfairness of the share of commodities offered tothe e-agent programs. Alternatively, non-linear terms in the utilityfunction may be approximated by a plurality of piece-wise linear terms.Where commodities are exchanged in whole commercial units, anyfractional commercial units generated by substantially maximizing thevalue of the utility function can be preferably reallocated among thee-agent programs in a fair manner, whereby only whole commercial unitsof commodities are actually offered.

In another aspect of the first embodiment, at least one of the e-agentprograms generates counter-offer messages by executing a program thatsubstantially maximizes the value of a utility function of the commodityamounts. Preferably, the utility function is determined according tomean-variance portfolio methods. Alternatively, the utility function isa difference of two terms, a first term representing the expected returnfrom a portfolio having the commodity amounts and a second termrepresenting the risk of a portfolio having the commodity amounts. Thesubstantial maximization of the utility function can be limited byoptional constraints.

In other aspects of the first embodiment, at least one of the e-agentprograms generates counter-offer messages by accepting all commodityamounts previously offered by the intermediary program up to certainpre-specified maximum commodity exchange bounds and also limited byoptional constraints. Optionally, at least one of the e-agent programsfor the associated participant generates counter-offer messages byexecuting procedural rules having variables referring to the commodityamounts. Optionally at least one of the e-agent programs is provided bythe associated participant. Optionally At least one of the e-agentprograms is memoryless. Optionally at least one of the participants isassociated with more than one e-agent programs. Optionally at least oneof the e-agent programs is an autonomously running computer process.Optionally at least one of the e-agent programs are executed on the samecomputer as the intermediary program. Optionally at least one of thee-agent programs are executed on computers geographically remote fromthe computer on which the intermediary program is executed.

In another aspect of the first embodiment, this first embodimentincludes communications means for sending digital informationrepresenting the electronic offer messages and the electroniccounter-offer messages between e-agent programs and the intermediaryprogram. The communication means can include the IP or the TCP/IPcommunication protocols. The communication means can also includeinter-process communication of an operating system of a computer runningat least one of the e-agent programs and the intermediary program.Alternatively, the communication means includes inter-computercommunication means between at least two of the computers where thee-agent programs and the intermediary programs are executed.

In another aspect of the first embodiment, the e-agent programs receiveelectronic order messages from computers of the associated participants.The order messages contain digital data representing the commodityexchange objectives of the associated participants. Also, theintermediary program can send electronic results messages to thecomputers of the participants. The results messages contain digital datarepresenting the results of an intermediated exchange. Alternatively,the digital data representing the commodity exchange objectives of theparticipants is tested before the electronic intermediated exchangebegins.

In other aspects of the first embodiment, the first embodiment alsoincludes interface programs that communicate with the computers of theparticipants for transferring the order messages and the resultsmessages between the computers and the intermediary program. Also, thefirst embodiment can include an exchange driver program running on atleast one computer, such that the interface programs communicate withthe intermediary program through the exchange driver program. Alsoincluded can be a database program running on at least one computer forstoring copies of the order messages and the results messages.Alternatively, the database, in case of a failure in the computersystem, can retrieve the copies of the messages in order to recover fromfailure. Also included can be a supervisor program running on at leastone computer, and for periodically testing each program of the computersystem to determine if it has failed.

In a second general embodiment, this invention comprises acomputer-based method for an electronic intermediated exchange of aplurality of commodities among a plurality of participants. This methodincludes the steps of: sending a plurality of electronic offer messagesgenerated by an intermediary computer program, which intermediates theintermediated exchange, to a plurality of e-agent computer programs,each e-agent computer program associated with and representing one ofthe participants, each electronic offer message including digital datarepresenting amounts of commodities offered to the e-agent programs bythe intermediary program; sending a plurality of electroniccounter-offer messages generated by the e-agent programs to theintermediary program, each electronic counter-offer message includingdigital data representing amounts of commodities accepted by the e-agentprogram; and repeating the previous steps in order, each orderedrepetition being a round of an electronic negotiation, until the amountsof commodities in the electronic offer messages are substantiallysatisfactory to the e-agent programs, according to exchange objectivesof the participants stored in the e-agent programs, and to theintermediary program, according to objectives for the intermediatedexchange stored in the intermediary program. Alternatively, therepetition of the first two steps terminates when the e-agent programsgenerate counter-offer messages representing acceptance of the totalamounts of commodities offered in the immediately preceding offermessages received from the intermediary program.

This second embodiment includes several more detailed and particularembodiments and aspects, such as the following. In one aspect, thecounter-offer messages generated by the e-agent programs representaccepted amounts of commodities that are less than or equal to amountsof commodities represented in one or more of the preceding offermessages received from the intermediary program, more particularly fromthe immediately preceding offer message.

In another aspect of the second embodiment, to generate offer messages,the intermediary program performs a first step of determining digitaldata representing a plurality of bounds, each bound representing amaximum amount of a particular commodity that can be offered to aparticular e-agent program in a current round of the electronicnegotiation, followed by a second step of generating the offer messagesrepresenting offered amounts of commodities less than or equal to theappropriate one of the bounds. Alternatively, the method furtherincludes, preceding the first step, a further step of sending aplurality of electronic opening messages from the e-agent programs tothe intermediary program, each opening message including digital datarepresenting maximum amounts of commodities participants will exchangein the intermediated exchange. The intermediary then sets the initialbounds to be these maximum amounts. Preferably, the bounds in a laterround of the negotiation are not greater than the bounds in an earlierround of the negotiation. Further, the plurality of bounds in a currentround of the negotiation can depend on commodity amounts represented inthe intermediary offer messages, the e-agent counter-offer messages, andthe bounds from one or more preceding rounds of the negotiation, moreparticularly from the immediately preceding round of the negotiation.

In another aspect of the second embodiment, the plurality of currentbounds depends on commodity amounts represented in the e-agentcounter-offer messages and on the bounds from the immediately precedinground of the negotiation. Alternatively, the plurality of bounds aredetermined to be a weighted average of commodity amounts represented inthe e-agent counter-offer messages and the bounds from the immediatelypreceding round of the negotiation. Further, after a selected round ofthe negotiation, the bounds can be determined to be equal to commodityamounts represented in the e-agent counter-offer messages from theimmediately preceding round of the negotiation.

In another aspect of the second embodiment, before the first step, themethod further can include various preliminary steps. Among thesepreliminary steps is a step of sending from the intermediary program tothe e-agent programs a plurality of electronic initial messages, eachinitial message including digital data representing the particularcommodities that can be exchanged in the intermediated exchange. Also,before the first step, the method can include a step in which thee-agent programs receive and store a plurality of electronic ordermessages from the participants. Each order message includes digital datarepresenting the exchange objectives of that participant. Anotherpossible preliminary step is a step of the intermediary programreceiving and storing electronic objective messages from an operator ofthe electronic intermediated exchange. The objective messages caninclude digital data representing the objectives of the intermediatedexchange. Additionally, after the last step, the method can include astep of sending a plurality of electronic results messages to eachparticipant. Each results message has digital data representing theamounts of commodities in the satisfactory offer message.

In a third general embodiment, this invention comprises a computer-basedmethod for representing a participant in an intermediated exchange ofcommodities, the intermediated exchange performed by an electronicnegotiation with an intermediary computer program. The method has thefollowing steps: receiving by an e-agent computer program an electronicorder message from a computer of the participant, the order messageincluding digital data representing the objectives of the participantfor the intermediated exchange in order that the e-agent program canrepresent the participant; receiving one of a plurality of electronicrequest messages from the intermediary program; and sending one of aplurality of electronic response messages to the intermediary program inresponse to the previous request message. The response message is (i) anopening message, if the previous request message was a query for anopening message, the opening message including digital data representingthe maximum amounts of commodities that the e-agent program willexchange in the intermediated exchange, and (ii) a counter-offermessage, if the previous request message was an offer message, the offermessage including digital data representing amounts of commoditiesoffered to the e-agent program by the intermediary program, thecounter-offer message including digital data representing amounts ofcommodities accepted by the e-agent program as determined according tothe exchange objectives, the accepted amounts being less than or equalto the offered amounts and being all equal to the offered amounts onlyif the offered amounts meet the exchange objectives.

This third embodiment includes several more detailed and particularembodiments and aspects, such as the following. In one aspect, themethod includes, between the first two steps, a further step ofexchanging one or more electronic initial messages between the e-agentprogram and the intermediary program, the initial messages includingdigital data representing commodities of interest to the participantaccording to the exchange objectives as determined by the e-agentprogram, and commodities participating in the intermediated exchangewith prices for the participating commodities as determined by theintermediary program.

In another aspect of the third embodiment, the exchange objectives ofthe participant can be expressed according to a variety of methods. In apreferred method, the exchange objectives are expressed according tomean-variance portfolio theory. More particularly, the exchangeobjectives are expressed as a utility function of commodity amounts.Commodity amounts in counter-offer messages are those that substantiallymaximize the utility function subject to maximum amount constraintsgiven by the previously offered commodity amounts. Further, the utilityfunction can include terms representing expected return and expectedrisk. In a further method, the exchange objectives are expressed asprocedural rules which determine accepted amounts of commodities fromoffered amounts of commodities.

A program for performing the method of this third embodiment can berecorded on a computer readable medium, either as encoded instructionsfor causing an electronic computer to function according to this methodor as human-readable instructions which can be compiled into suchencoded instructions.

In a fourth general embodiment, this invention comprises acomputer-based method for an intermediated exchange of commodities amonga plurality of participants, each participant represented by an e-agentcomputer program. The method includes the following steps: sendingelectronic opening messages to an intermediary computer program from thee-agent programs, the opening messages including digital datarepresenting the maximum amount of each commodity that each e-agentprogram will exchange in the intermediated exchange; sending electronicoffer messages by the intermediary program to the e-agent programs, eachoffer message including digital data representing amounts of commoditiescurrently offered to each e-agent program, the amounts being determinedso that for each commodity the amount being offered for sale by all thee-agent programs equals the amount being offered for purchase by all thee-agent programs; receiving electronic counter-offer messages by theintermediary program from the e-agent programs, each counter-offermessage including digital data representing amounts of offeredcommodities accepted by each e-agent program, the accepted commodityamounts being less than or equal to the offered commodity amounts;repeating the previous two steps in order, each ordered repetition beinga round of an electronic negotiation, until the e-agent programs acceptall the amounts of commodities offered, the accepted amounts being finalcommodity amounts; and sending results electronic messages to computersof the participants, the results messages including digital datarepresenting the final commodity amounts.

This fourth embodiment includes several more detailed and particularembodiments and aspects, such as the following. In one aspect,additional steps can precede the first step of this method. One suchadditional step includes exchanging one or more electronic initialmessages between the intermediary programs and the e-agent programs. Theinitial messages can include digital data representing commodities thatthe e-agent programs will exchange in the intermediated exchange, andcommodities actually participating in the intermediated exchange withtheir prices. Further initial message can include digital datarepresenting the particular commodities available for exchange in theintermediated exchange.

In another aspect of the fourth embodiment, the second step can furtherinclude that the intermediary program, first, determine digital datarepresenting a plurality of bounds, each bound representing a maximumamount of a particular commodity that can be offered to a particulare-agent program in a current round of the electronic negotiation, andsecond, generates the offer messages representing offered amounts ofcommodities that are less than or equal to the bounds. The intermediarycan determine the bounds initially to be the opening maximum amounts.Preferably, the bounds in a later round of the negotiation are notgreater than corresponding bounds in an earlier round of thenegotiation.

In another aspect of the fourth embodiment, the plurality of bounds in acurrent round of the negotiation can depend on commodity amountsrepresented in the intermediary offer messages, the e-agentcounter-offer messages, and the bounds from one or more preceding roundsof the negotiation, more particularly from the immediately precedinground of the negotiation. Alternatively, the plurality of current boundscan depend on commodity amounts represented in the e-agent counter-offermessages and on the bounds from the immediately preceding round of thenegotiation. More particularly, the plurality of bounds can be aweighted average of commodity amounts represented in the e-agentcounter-offer messages and the bounds from the immediately precedinground of the negotiation. Alternatively, after a selected round of thenegotiation, the bounds are determined to be equal to commodity amountsrepresented in the e-agent counter-offer messages from the immediatelypreceding round of the negotiation.

A program for performing the method of this fourth embodiment can berecorded on a computer readable medium, either as encoded instructionsfor causing an electronic computer to function according to this methodor as human-readable instructions which can be compiled into suchencoded instructions.

In a fifth general embodiment, this invention comprises an order-managercomputer system for electronic intermediated exchange of a plurality ofcommodities among a plurality of participants. The order-manager systemcomprises: a plurality of client-interface electronic processes forcommunicating with computers of the participants in order to receivefrom the participants electronic order messages representing exchangeobjectives of the participants and to send to the participantselectronic results messages representing the commodities exchanged inthe intermediated exchange; an exchange-driver electronic process fortransferring the order messages and the results messages between theclient interface processes and an intermediary electronic process; anelectronic database for storing copies of the order and the resultsmessages, and in event of process failure in the order-manager system,for retrieving the message copies in order to restart the failedprocess; a plurality of e-agent electronic processes, each e-agentprocess for representing one of the participants according to theexchange objectives by generating electronic counter-offer messages sentto the intermediary process in response to electronic offer messagesreceived from the intermediary process; and the intermediary electronicprocess for generating the offer messages sent to the e-agent processesin response to the counter-offer messages received from the e-agentprocesses, the exchange of offer and counter-offer messages beingaccording to a protocol for performing the intermediated exchange, andfurther for generating the results messages when the intermediatedexchange completes. Optionally, this embodiment further includes aplurality of computers for executing the processes of the order-managersystem, the computers interconnected by communication means.

This fifth embodiment includes several more detailed and particularembodiments and aspects, such as the following. In one aspect, the offermessages and the counter-offer messages include digital datarepresenting amounts of commodities. Accordingly, the protocol specifies(i) that the amounts of commodities represented in the counter-offermessages are less than or equal to the amounts of commoditiesrepresented in immediately preceding corresponding offer messages, and(ii) that the amounts of commodities represented in the offer messagesare less than or equal to the amounts of commodities represented inimmediately preceding corresponding offer messages.

In other aspects of the fifth embodiment, this embodiment can includeadditional elements. Such additional elements are a supervisor processfor periodically testing other processes of the order-manager system forfailure, and in case of failure, for managing restart of the failedprocess, and a slave-supervisor process for periodically testing thesupervisor process for failure, and in case of failure, for assuming thefunctions of the supervisor process. Other additional elements include aticker plant process for providing digital data representing the pricesof the commodities, and a tape reporting process for forwarding resultsof an intermediated exchange for public reporting. Alternatively, theintermediary can include, in turn, a communications interface componentfor communicating messages between the intermediary process and theexchange driver process and the database, an allocation component forperforming the computations for generating the offer messages, and alocal data area component for storing data to be exchanged between thecommunication interface function and the allocation function.

4. BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the presentinvention will become better understood by reference to the accompanyingdrawings, following description, and appended claims, where:

FIG. 1 schematically illustrates software that performs the principalfunctions of this invention;

FIG. 2 is a flow chart of a process performed by the software of FIG. 1;

FIG. 3 schematically illustrates a preferred protocol for the process ofFIG. 2;

FIG. 4 schematically illustrates an embodiment of an order-manager ofthe system of this invention;

FIG. 5 schematically illustrates in greater detail the order-manager ofFIG. 4;

FIG. 6 schematically illustrates in greater detail an intermediarymachine depicted in FIG. 5;

FIG. 7 schematically illustrates internal data messages of theintermediary machine of FIG. 6;

FIG. 8 schematically illustrates e-agent data messages used in theintermediary machine of FIG. 6;

FIG. 9 is a flow chart of a process for an e-agent used in theintermediary machine of FIG. 6;

FIG. 10 is a flow chart of a process for an intermediary machine of FIG.6; and

FIG. 11 schematically illustrates external data messages used in theintermediary machine of FIG. 6.

5. DETAILED DESCRIPTION

For clarity of disclosure, and not by way of limitation, the preferredembodiment of this invention is described in detail with respect to theexchange of financial commodities. However, this invention is not solimited, and from the following detailed description it will be apparentto one of skill in the art that this invention is applicable toexchanges of tangible or intangible commodities of any sort. Forexample, it can be applied to the exchange of tangible commodities suchas agricultural, mineral, and manufactured products, or exchange ofintangible commodities such as contracts for the future exchange oftangible or intangible commodities.

5.1. E-Agents and the Intermediary

This invention provides substantially simultaneous exchange ofcommodities between participants represented by electronic agents,e-agents, that interact with an electronic intermediary in order tofacilitate negotiations leading to the exchange. The intermediary andagents are implemented in the preferred embodiment as software processesrunning on one or more computer systems. The agents conduct negotiationsby exchanging electronic messages with the intermediary. This subsectiondescribes the following: (1) typical electronic negotiations leading toan intermediated exchange according to the preferred embodiment of thisinvention; (2) general software and hardware architecture for thisembodiment; and (3) a preferred process and protocol for the exchange ofmessages.

By way of illustration, the process of typical electronic negotiationsare described here, first, for a simpler case of an exchange between twoparticipants, and subsequently, for an exchange between three or moreparticipants, the preferred application of this invention. Although thesimpler case is described as a negotiation directly between twoe-agents, without an intermediary, as will become apparent later, anintermediary according to this invention can provide assistance inrealizing a satisfactory exchange even in the simple case. Morespecifically, in advance of the negotiation, the participantselectronically instruct their respective e-agents about the criteria fora satisfactory final exchange of the commodities of interest.Thereafter, the electronic negotiation begins with an opening messagefrom each e-agent that establishes the bounds within which a finalexchange must lie, that is the maximum and minimum amounts of eachcommodity the e-agent is prepared to buy or sell. Then, the electronicnegotiation proceeds in a series of rounds, in which each e-agentconsiders the current offer from the other e-agent and makes acorresponding counter-offer. After a certain number of rounds of thiselectronic negotiation, the offers and counter-offers typically convergeso that the amounts of each commodity to be exchanged are acceptable toboth participants, according to their initial electronic instructions.At this point the negotiation terminates, and the parties can thenproceed to perform the exchange according to the amounts negotiatedusing means known in the art.

In the more complex case of the preferred embodiment, three or moreparticipants electronically negotiate a common exchange through theirrespective e-agents and a single, trusted electronic intermediary. Theintermediary is designed to represent the interests of all theparticipants in such a manner that each e-agent needs only to conduct atwo-party electronic negotiation with the intermediary, whichnegotiation proceeds according to a process substantially similar to thesimpler case discussed above. Without such an intermediary, each of the,say N, agents would need to negotiate directly and individually with allof the other agents, requiring on the order of N² negotiations. However,the intermediary, as provided by the preferred embodiment, facilitatesthe electronic exchange by requiring only on the order of N directnegotiations with each e-agent individually.

Preferably, the intermediary should be programmed to act fairly by notfavoring any of the agents and by promoting a greater volume ofexchanges. An exchange among electronic agents using the services of atrusted electronic intermediary also proceeds, as in the simpler caseabove, as a several step process. First, after the e-agents receiveelectronic instructions from their participants, the negotiation openswith each e-agent informing the intermediary of the bounds within whichmust lie an acceptable deal. Using this information, the intermediarypresents each e-agent with an initial offer that is constructed byallocating to each e-agent, according to whether it wishes to buy orsell a given commodity, a share of the total of all the offers to sellor to buy, respectively, of that commodity. This process is known as"crossing" and "allocating" the "buys" with "sells." In the followingsteps, the e-agents receive further offers from the intermediary andreturn counter-offers to the intermediary, which it again crosses andallocates so as to generate new offers to all of the agents. The processof electronic negotiation is designed so that for a typical case, afterseveral rounds of this negotiation all the agents will be "satisfied"with their offers from the intermediary for the commodities beingexchanged, and the negotiation will terminate.

This invention is equally adaptable to exchanging portfolios of severallinked commodities as well as individual commodities. A portfolio ofcommodities is a group of commodities collectively having or requiringcertain characteristics. In the case of financial commodities, suchcharacteristics include, for example, total cost, overall expectedreturn, overall expected risk, certain weightings with respect toindustrial sectors or to benchmark portfolios (such as the S&P 500), andso forth.

In the following detailed description, an "offer" for a commodity is anelectronic message sent from an intermediary to an e-agent that includesthe amount of the commodity that the intermediary has made available tothe e-agent to buy or sell at a given stage of the electronicnegotiation. A "counter-offer" for a commodity is an electronic messagesent from the e-agent to the intermediary that includes the amount ofthe commodity that the e-agent intends to buy or sell at this stage ofthe electronic negotiation. An "opening" for a commodity is an initialelectronic message sent from an e-agent to the intermediary thatincludes the maximum amount of a commodity that the e-agent intends tobuy or sell in a given negotiation. Preferably, offers, counter-offers,and openings contain data for all the commodities to be exchanged in oneelectronic message.

5.1.1. The System of Intermediated Exchange

FIG. 1 generally illustrates the software architecture of the system forautomated intermediated exchanges of the preferred embodiment. FIG. 4shows an implementation of this architecture in greater detail.

Turning first to FIG. 1, each participant who wishes to exchangecommodities is represented by a software agent, such as 1, known as anelectronic agent or an e-agent. An electronic intermediary 3, conductselectronic negotiations individually with e-agents 1 in order to arriveat a successful intermediated exchange of commodities. The negotiationis facilitated by the exchange of electronic messages 2, transmittedbetween the e-agents and the intermediary.

As illustrated in FIG. 1, e-agents 1 communicate only with theintermediary 3 and not with each other. Since the intermediary and ane-agent exchange only offers and counter-offers relative to that agent,no e-agent is "aware" of any other e-agent's activities. Thus, alle-agents act substantially independently and all commodities aresubstantially fungible among the e-agents. Further, in the preferredembodiment, the intermediary actively initiates all message exchanges,while each e-agent waits passively for and responds to messages from theintermediary.

E-agents 1 evaluates offers from the intermediary and generatecounter-offers to the intermediary in order to arrive at an exchange ofthe commodities consistently with the participant's objective. In thepreferred embodiment the intermediated exchanges occur periodically,e.g., preferably every 90 minutes. Typically, each participant specifiesthe commodities of interest and corresponding objectives to its e-agentjust before each intermediated exchange, as these objectives areexpected to change between sessions. The specification of commodities ofinterest can for example be provided as a list by means known in thecomputer arts. Where these commodities form a portfolio, data providedto an e-agent includes the characteristics of the portfolio, forexample, risk, expected return, and sector allocations.

The objectives of a participant can be provided to the e-agent processaccording to the following options. According to one option, theparticipant provides to the system of this invention the entire programthat is executed by the e-agent process and that encodes theparticipant's objectives. According to another option, the participantselects one of e-agent programs already provided by the system andsupplies parameters to tailor the selected program to the participant'sobjectives. For example, according to this option, a participant canselect a rule interpreter and provide it with a list of procedural ruleswhich the selected interpreter uses to evaluate an offer from theintermediary and to generate a counter-offer. In the preferredembodiment, the participant selects a program capable of findingsubstantially the extremum of an objective function of amounts ofcommodities to be exchanged, as limited by optional constraints, andsupplies parameters defining the precise form of the objective functionand constraints. The e-agent then generates counter-offers bysubstantially maximizing the defined objective function. This option isreferred to as substantially maximizing the "utility" function of theparticipant. Other ways of evaluating offers and generatingcounter-offers can be employed.

Software intermediary 3 sums the commodity amounts offered for exchangein the opening and counter-offer messages of the participating e-agents,allocates these total amounts among the e-agents, and generatescommodity offers to send back to the e-agents. In general, it is usuallypreferred that the intermediary act substantially fairly in not favoringone e-agent over another. One measure of fairness is that all offers areat least partially satisfied on a pro-rata basis. Beyond this generalpreference, commodity allocation can be done in many manners reflectingobjectives of the participants and the type of commodities exchanged.For example, for commodities whose value decrease over time, such as forperishable agricultural commodities, it can be preferable to allocatethe oldest, fresh commodities first. In the preferred application ofthis invention to exchanges of financial commodities, and similarly forother fungible commodities, it is desirable that commodities beallocated such that the total amount of commodities exchanged issubstantially maximized. Therefore, the electronic intermediaries of thepreferred embodiment, to which the remainder of this description isgenerally directed, attempts to fairly allocate the maximum amounts ofcommodities.

The goals for the commodity allocation, e.g., fairness and maximumexchange, can conflict, and an electronic intermediary can resolve suchconflicts and perform acceptable allocations in various ways. In thepreferred embodiment, each exchange is treated separately, and theelectronic intermediary seeks commodity allocations for each round ofthe negotiation that trades off maximum amounts exchanged with maximumallocation fairness. In the preferred implementation, allocationfairness and the amounts exchanged are expressed as functions of amountsof individual commodities offered to the e-agents. Amounts for an actualoffer are determined by the maximum, or an approximate maximum, of aselected combination of these functions. (Both the "maximum" and the"approximate maximum" will be referred to as "maximum"). Further, thismaximum must be consistent with any e-agent constraints. For example,one such constraint is that each e-agent is willing to exchange onlylimited, maximum amounts of each commodity. Other constraints are, forexample, minimum amounts to exchange, tiering constraints, which listcertain other e-agents with which this agent is unwilling to exchange,and so forth. This maximum can be found by known techniques ofmathematical programming and optimization known in the arts that areappropriate to the form of the functions chosen. Such techniques includethe simplex method, the maximum flow method, or the barrier method inconjunction with branch-and-bound techniques. See, e.g., Gonzaga, 1992,Path-following methods for linear programming, SIAM Review 34(2):167-224; Karloff, 1991, Linear Programming, Birkhauser;Papadimitriou et al., 1982, Combinatorial Optimization, Prentice-Hall.In other embodiments fairness can be maintained only on average over aplurality of separate intermediated exchanges, with each single exchangesubstantially maximizing amounts exchanged in a not necessarily fairmanner. In this case, allocations can then be made by a rule interpreterwhich interprets agreed rules governing longer term fairness tradeoffswhile substantially maximizing amounts exchanged at each offer.

The hardware and software architecture of the preferred embodiment areillustrated in FIG. 4. Generally, the various software functions of thisinvention are implemented as software processes, such as intermediaryprocess 3 and e-agent process 42-46, that can be running on differentcomputers, such as intermediary computer 40 or participant computer 47.These computers are connected by at least one communication networkwhich provides communication links, such as communication link 55, forthe exchange of messages between the processes.

As FIG. 4 illustrates, the software processes can be distributed acrossthe various computers. For processes to be freely distributable it ispreferable that they be separately addressable nodes of a generalelectronic communication network. Such a preferred network is oneconstructed using the TCP/IP protocols, and can thus be implementedusing a private intranet or the public Internet. Such a TCP/IP networkcan transparently link processes on one or more computers. However, forthose processes known to reside only on one computer, it is often moreefficient that the operating system's facilities for inter-processcommunication serve as the communication network, using process-ids foraddresses. Actual process distribution in a particular embodiment isgenerally determined by cost, response-time, and throughputconsiderations, as known in the computer arts, as well as byrequirements of the participants for security and control of their owne-agent processes.

E-agents are preferably single processes, each executed on theappropriate and convenient computer. In some instances, participantsrequire direct control of their e-agent computers, for example, forsecurity reasons. FIG. 4 illustrates such an instance in which singlee-agent process 44 executes on participant computer 49. Participantterminal 50, attached to computer 49, inputs to the e-agent theparticipant's commodities of interest and exchange objectives andoutputs to the participant the results of the negotiated exchanges amongall the e-agents conducted by electronic intermediary 3. In anotherinstance, participant computer 47 executes two e-agent processes 45 and46 because this participant controls two independent and differentportfolios of commodities which these two separate e-agents manage. Inother cases, e-agents can execute remotely from their participants. Forexample, e-agent processes 42 and 43 reside on the intermediarycomputer(s) 40. These e-agents are accessed by terminals, such asparticipant terminal 52 attached through link 56, which can either be alocal or a long-distance link to computer 40.

The computers that run e-agent processes preferably enable e-agents torespond rapidly to intermediary offers in order that the intermediatedexchange not be unduly delayed. When it is necessary that an exchange becompleted as rapidly as possible, as in the case of financialcommodities, e-agents preferably reside locally with the intermediary,as e-agents 42 and 43 in FIG. 4, so that the system response times canbe optimized. Exemplary e-agent computers include Sun Microsystems Sparc20, Compaq Deskpro 6000, and the IBM RS6000.

Intermediary 3 is also preferably implemented as one or more processesexecuted on one or more computers, each intermediary process having oneor more threads of execution. Intermediary computer(s) 40 issufficiently capable to meet computational and turnaround timerequirements of a particular embodiment. If a single computer is notsufficiently capable, the intermediary can be parallelized into multiplecooperating and parallel processes or threads in ways known in thecomputer arts. In this case, computer 40 can be a local network ofcomputers or, alternatively, a single parallel computer. For example, ina preferred embodiment directed to financial commodities and especiallyequities, the turnaround time for an intermediated exchange is typicallyrequired to be less than 90 secs. and, preferably, computer(s) arechosen to be sufficiently powerful to meet such a turnaround time. Forexample, Sun UltraSparc systems can be used for computer(s) 40.

Also, optionally, certain e-agents can be implemented as part of theintermediary process or processes. Such e-agents are those withparticularly limited computational requirements. By implementing thesee-agents within the intermediary the system can reduce communicationdelays and, thereby, improve performance.

Various alternative distributions of the software to processes andthreads, and the processes and threads to physical computers areapparent to one of skill in the computer art. Such specificdistributions are governed by computational demands and computer costs.

FIG. 4 also illustrates communication links to external data gateways.Since the intermediary of the preferred embodiment of this inventiondoes not determine prices, this information is obtained from externalsources that report prevailing commodity prices in markets acceptable tothe electronic agents involved in an exchange. Thus, price data source53 is linked to the intermediary computer 40. Also, for certaincommodities, in particular for financial commodities, laws andregulations dictate the prompt, public reporting of all exchanges ofthose commodities. In this case, successful exchanges are appropriatelyreported at 54 as well as to the participants.

5.1.2. The Method of Intermediated Exchange

FIG. 2 illustrates in more detail the process of the electronicintermediated exchange of the preferred embodiment, which is asynchronized sequence of exchanges of offers and counter-offers betweenthe electronic intermediary and the e-agents. Preliminary to the stepsof FIG. 2, the intermediary, which represents the joint goals of a groupof agents that might seek to exchange certain commodities, isconstructed. Preferably, the intermediary for a certain group ofparticipants is constructed on the basis of a parameterized utilityfunction with constraints that reflect the interests of the group ofparticipants. That intermediary then facilitates exchanges executedaccording to the steps of FIG. 2.

Generally, at step 10, the participants instruct their e-agentsregarding the exchange objectives; at step 11, the e-agents submitopening messages to the electronic intermediary; at step 12, theintermediary generates initial offer messages to the e-agents; at step13, the e-agents respond with counter-offer messages; step 14 tests forsuccessful completion of the electronic negotiation; and at step 15 ifthe exchange is not yet completed, the intermediary generates furtheroffers to the e-agents. Steps 13, 14, and 15 are repeated until thenegotiation completes according to the test of step 14. Alternatively,the negotiation can be terminated after a pre-determined number ofsteps, whether or not this test is met.

More specifically, at step 10, each participant specifies to its e-agentthe commodities of interest, as well as objectives and constraints forevaluating offers and for generating counter-offers. In the preferredembodiment, objectives and constraints are provided as parameters thatdefine an instance of a utility function of commodity amounts exchanged,along with optional associated constraints. The maximum of theconstrained utility function determines the counter-offer amounts.Alternatively, a participant can supply rules that when interpreted orexecuted evaluate offers and generate counter-offers. Also, aparticipant can supply an entire e-agent program.

Based on their exchange objectives, at step 11, the e-agents send to theelectronic intermediary opening messages indicating all the commoditieswhich an e-agent can exchange and for each, the maximum amounts toexchange. In the opening message, an e-agent may specify that it iswilling to both buy and sell the same commodity if, for example, itsfinal decision to buy or to sell that commodity is based on theavailability of other commodities in the exchange.

In general, the opening, offer, and counter-offer messages may have buyand sell requests for the same commodity. These are called herein the"buy side" and the "sell side" for a commodity. In the example below,Moe, Larry, and Curly want to exchange PG&E stock, PCs, and plums, andthey have instructed their agents to make the following openings.

                  TABLE 1    ______________________________________    Example of an Opening    Buy Side           Sell Side    Agent  PG&E    PCs     Plums PG&E    PCs  Plums    ______________________________________    Moe    16      10            16           10    Larry  10              6             5    Curly  10      15                         10    TOTAL  36      25      6     16      5    20    ______________________________________

In this example, Moe has indicated that, in this particular exchange, hemight buy up to 10 PCs or sell up to 10 plums, but not more. Further, hehas indicated that he might buy or sell up to 16 shares of PG&E,depending on how the negotiation progresses.

Based on the information provided by the opening messages, at step 12,the intermediary generates initial offer messages listing commoditiesoffered and sends them to the e-agents. Because the e-agentscollectively may seek to purchase more units of a commodity than theyseek to sell, or vice versa, the intermediary's initial offer for eachcommodity allocates the total quantity offered by all the e-agents amongall the e-agents interested in buying or selling. As discussed above,this allocation is preferably done fairly, and, in the case of financialand similar commodities, so as to substantially maximize the totalamount exchanged. This allocation preferably satisfies a set of "basic"constraints on the exchange set by the e-agents. One such constraint isthat each e-agent is willing to exchange only a certain maximum amount,as communicated in the opening message. Other e-agent constraints, forexample, include: (i) a minimum amount of a commodity that must beexchanged by an e-agent for any exchange to occur; (ii) a group of othere-agents not eligible for exchange with this e-agent; (iii) a refusal toaccept fractional units of a commodity; and so forth. As described,different intermediary goals can be appropriate for different groups ofparticipants exchanging other types of commodities.

Continuing with the previous example of Moe, Larry, and Curly, assumethat these participants have selected an intermediary that attempts tosubstantially maximize the total amount of commodities exchanged whilefairly allocating amounts according to a pro-rata scheme. Accordingly,an offer can contain the following allocations. Since only Larry wantsto buy plums while Moe and Curly want to sell equal amounts of plums,Larry can be initially offered a purchase of 6 plums, 3 each from Moeand Curly. Since only Larry wants to sell PCs while Moe and Curly wantto buy PCs in the ratio of 2/3, Larry can be initially offered a sale of5 PCs, with 2 going to Moe and 3 to Curly. Finally, to maximize thecommodities exchanged, Moe can be initially offered a sale of all 16shares of PG&E to be divided equally between Larry and Curly. Furtherrounds of counter-offers and offers can modify these initial offers toreach a successful exchange for all participants.

At the next step 13, each e-agent evaluates its current offer from theintermediary, either an initial offer or an offer during a subsequentround of electronic negotiation, and responds with a counter-offer. Inthe preferred embodiment, this evaluation is determined by the amountsoffered in the last offer from the intermediary together with initialinstructions from the participant. In other words, an e-agent of thepreferred embodiment is "memoryless" in that it does not look back toprior offers from the intermediary at any given round of negotiation,but rather computes a counter-offer only from the offer just received.In an alternative embodiment, an e-agent may act tactically orstrategically to try to increase its utility by considering a sequenceof several offers and counter-offers at a given round of negotiation.Such an e-agent, however, can prevent other e-agents from obtainingdesired outcomes, and therefore is less preferred.

A memoryless e-agent of the preferred embodiment can use itscounter-offer to signal certain preferences to the intermediary. Forexample, the e-agent can signal its interest in a particular commodityby a counter-offer to take all, or substantially all, of that commodity.Further, the e-agent can signal its satisfaction with the offer as awhole by returning a counter-offer that is identical to the precedingoffer. As described, in the preferred embodiment, an e-agent evaluatesprevious offers according to a "utility" function, together withoptional constraints, whose joint extremum determines the counter-offerto a prior offer. Alternatively, the e-agent can use a set of rules,such as expressed in a programming language format, for evaluatingoffers.

At step 14, the negotiation successfully terminates if all the e-agentssignal that they are satisfied with their last offers from theintermediary. Preferably, they do this by returning counter-offers thatare equal to the previous offers. Alternatively, the negotiation can beterminated after a predetermined number of steps of negotiation, whetheror not all the e-agents signal satisfaction. Upon termination, theparticipants actually exchange the agreed upon amounts of thecommodities using any mutually acceptable known means.

If the negotiation did not terminate at step 14, then at step 15, theintermediary generates new offers by a process similar to that forgenerating initial offers, that is, it allocates commodities amonge-agents based on fairness, substantially maximizing commodity exchange,and satisfaction of e-agent basic constraints. Preferably theintermediary, unlike e-agents, has a memory of the recent rounds ofnegotiation, so that it can generate offers that depend on previousoffers and counter-offers. In the preferred protocol, describedsubsequently, the intermediary generates offers based on the immediatelypreceding counter-offer and the immediately preceding offer.

The Protocol for Intermediated Exchanges of the Preferred Embodiment

In the preferred embodiment the negotiation between the intermediary andthe e-agents proceeds according to a protocol which leads to (1) asubstantially satisfactory outcome of the negotiated exchange accordingto the goals of the participants and the intermediary, and (2) a nearoptimum solution for commodity exchange according to the particulare-agent and intermediary utility functions or exchange rules adopted toreflect these goals. Time requirements on completion of an intermediatedexchange, as are present for financial commodities, may require the useof approximations or heuristics in order to perform the computations ofthe intermediated exchange in the required time. This preferred protocolincludes the following rules:

E-agent Rule:

(i) The amount of a commodity in the current counter-offer generated byan e-agent is less than or equal to the amount of that commodity in theimmediately preceding intermediary offer; and

(ii) The current e-agent counter-offer depends only on commodity amountsin the immediately preceding intermediary offer.

Intermediary Rule:

(i) The amount of a commodity in an offer to an e-agent being generatedby the intermediary is chosen to be less than or equal to the "currentdemand," which is an upper bound for that commodity and that e-agentthat varies during the negotiation, and to satisfy the applicable set ofbasic e-agent constraints; current demands for an e-agent do not changeif the immediately preceding offer is equal to zero, or if theimmediately preceding counter-offer equals the immediately precedingoffer; and

(ii) Preferably, the current demand, and thus the amounts in the currentintermediary offer, depends on both the last offer, the lastcounter-offer, and on the round of the negotiation; further the currentdemand is less than or equal to the immediately preceding demand andgreater than or equal to the amount in that e-agent's immediatelypreceding counter-offer.

It is preferred that the amounts to be offered next by the intermediarybe close to the demands, and that these amounts are between the amountsin the e-agent's immediately preceding counter-offer and the amounts inthe intermediary's immediately preceding offer. Accordingly, thee-agents are presented with opportunities to obtain the maximumsatisfactory commodity exchange, at least for those amounts in whichthey expressed an interest in their most recent counter-offers.

However, since such desirable offer amounts cannot, in general, beguaranteed, the demands in the preferred protocol are targets for theintermediary's next offer. In particular, the intermediary should alwaysbe able to arrange some satisfactory commodity exchange. A failure ofoffer determination, and a consequent failure of an intermediatedexchange, is undesirable for exchange participants. Depending on theintermediary's offer selection method and its constraints, imposing alower bound on the offers, such as the e-agents' previouscounter-offers, can result in such a failure to determine next offersfor all the e-agents. For example, lowering a bound for an intermediarythat uses optimization to determine offers may cause offer amounts to beless than the amounts in which an e-agent previously indicated aninterest. Therefore, the demands or bounds are treated as targets forthe intermediary to generate is offers. It is preferable that theresulting offers are close to the demands. However, in an alternativeintermediary implementation, where lower bounds can be specified withouta risk of failure, a preferred lower bound is the e-agent's immediatelyprevious counter-offer. In such an implementation, the actualintermediary offer, not just the upper bounds, would lie between theimmediately preceding e-agent counter-offer and the immediatelypreceding intermediary offer.

In more detail, FIG. 3 illustrates the protocol of the preferredembodiment with reference to the steps of FIG. 2. E-agent process 20 andintermediary process 21 are illustrated as exchanging the followingmessages as time increases: opening message 22 generated by step 11 ofFIG. 2, initial offer message 23 generated by step 12, firstcounter-offer message 24 generated by step 13, second offer message 25generated by step 15, second counter-offer message 26 generated by step13, and so forth. Also illustrated are amounts of commodity A in thesemessages. For example, opening message 22 indicates that the maximumamount of A that e-agent 20 is prepared to exchange is a_(max).Similarly, a_(n), where n is from 2 to 5, is the amount of A that isoffered or counter-offered in the subsequent messages illustrated inFIG. 3. Further, d_(n) is the current demand for a particular commodityfor a particular e-agent.

More specifically, this exchange begins at step 11 of FIG. 3, whene-agent process 20 sends opening message 22 indicating the maximumamount of commodity A, a_(max), that it is willing to trade in thisintermediated exchange. In step 12, intermediary process 21 sets thecurrent demand for A, d₂, to be equal to the opening maximum amount,a_(max), allocates the opening amounts of A among the interestede-agents as described above, and then generates initial offer message 23to e-agent process 20. According to the Intermediary Rule of thepreferred protocol, the amount offered to the e-agent is equal to orless than the current demand, that is:

    a.sub.2 <d.sub.2                                           (1)

During step 13, e-agent process 20 evaluates its offer and determines acounter-offer, substantially optimum according to its utility function,for all the commodities in which it is interested. According to theE-agent Rule of the preferred protocol, the e-agent is not constrainedin this determination as long as it uses only the preceding offermessage 22, and its counter-offer for A is less than or equal to theprevious offer for A, that is:

    a.sub.3 (a.sub.2)<a.sub.2                                  (2)

If all the e-agents are not satisfied, then, during step 15, theintermediary process generates new offers to all the e-agents. Accordingto the Intermediary Rule, if an e-agent does not counter-offer to takeall that was offered of a commodity in the previous offer, theintermediary selects that e-agent's next demand, d_(n), according to theIntermediary Rule. That is, in general, this demand, or upper bound, isgiven preferably by:

    a.sub.n-1 ≦d.sub.n =d.sub.n (a.sub.n-1,a.sub.n-2,d.sub.n-2, n, . . . )≦d.sub.n-2                                        (3)

Here, "a_(n-1) " denotes the amount in the immediately preceding e-agentcounter-offer; "a_(n-2) " denotes the amount in the immediatelypreceding intermediary offer; "d_(n-2) " denotes the demand for thegeneration of the immediately preceding intermediary offer; and "n"denotes the current stage of the negotiation. The " . . . " denote thatthe demand can depend on additional variables in alternativeembodiments. Thus, second offer message 25 proposes quantity a₄ ofcommodity A which satisfies:

    a.sub.4 ≦d.sub.4 (a.sub.3,a.sub.2,4)≦d.sub.2 (4)

Preferably, the actual offer amount, as well as the demand, is betweenthe previous offer, that is a₂, and the previous counter-offer, that isa₃.

    a.sub.3 ≦a.sub.4 ≦a.sub.2                    (5)

However, if this condition cannot be satisfied, this preference isdropped and only equation 4 is satisfied.

Finally, FIG. 3 illustrates further counter-offer message 26 in whichthe e-agent responds according to the E-agent Rule with counter-offeredquantity satisfying:

    a.sub.5 (a.sub.4)≦a.sub.4                           (6)

The preferred protocol is accompanied by heuristic rules for determiningthe demands or bounds, d_(n). These heuristic rules preferably balanceseveral competing requirements, including requirements for rapid andefficient convergence of the protocol to a final exchange, requirementsto substantially maximize the total amounts of commodity exchanged, andrequirements for overall fairness of the exchange. To insure convergenceof the negotiation, it suffices that, for every round beyond some pointin the negotiation, there is at least one commodity for which the newdemand, d_(n), is less than the previous demand, d_(n-2) for thatcommodity. In other words, preferably, there is some negotiation stage,denoted by N, such that for all rounds, n, of the negotiation beyond N,n>N, there is at least one commodity for which the following equation istrue.

    d.sub.n (. . . ,n, . . . )<d.sub.n-2 (. . . ,n-2, . . . )  (7)

This insures convergence of the negotiation, because then the sequenceof the sums of the demands of all the e-agents is decreasing. Sincecommodities are exchanged in pre-determined, integer units, the amountsoffered to each e-agent must eventually stop decreasing, arriving at asuccessful exchange for all e-agents. The speed of convergence dependson the rate of decrease of the demands, the more rapid the decrease thefewer rounds of negotiation are required for convergence.

However, it is preferable that the heuristic rules balance convergencerequirements against requirements for a maximal commodity exchange. Toencourage the e-agents to respond with larger counter-offers, andthereby to obtain a larger final intermediated exchange, it ispreferable for the intermediary to present larger offers. In otherwords, it is preferable that the demands or bounds, d_(n), not bedecreased rapidly. In one extreme case, if the demands were not reducedat all, a maximal exchange would occur if the negotiation converged.However, in this case, it may not. In an opposite extreme case, if thedemands are merely set to the amount in the e-agents' counter-offers,the intermediary then only allocates the counter-offers from thee-agents without modification. Thus, each offer will be less than orequal to the proceeding counter-offer amount. Such a rule may sharplyreduce the amounts of commodities exchanged because each e-agent acts inisolation and in a memoryless fashion. For example, if one e-agentlinked the exchange of two commodities together, a low offer for thefirst commodity can result in a low counter-offer for both the first andsecond commodities, which can sharply restrict the amount of the secondcommodity finally exchanged if this e-agent is a major supplier of thatcommodity in this exchange.

Therefore, it is desirable that the heuristic rules specify that thedemands, or upper bounds, decrease at an intermediate rate during thecourse of the negotiation. In this manner convergence occurs while theintermediary generates offers that permit the e-agent to explore thegreatest range of possible satisfactory exchanges.

Heuristic rules are chosen to satisfy the joint goals of theparticipants and the intermediary with respect to convergence, exchangesize, and fairness. There rules can be determined empirically byrerunning past intermediated exchanges, using, for example, the previouse-agent instructions provided by the participants along with otherprevious data, with different heuristics. A satisfactory heuristicachieves, on average during such reruns, the greatest commodity exchangewithin whatever time constraints determine the required rate ofconvergence. For example, for financial equities, convergence must occurin no more than approximately 90 seconds. Satisfactory heuristic rulessubstantially maximize total commodity exchanges within this time limitfor those e-agents and e-agent parameters likely to be used by theparticipants. Optimal heuristic selection is preferably an on-goingprocess. The participants are likely to change their e-agentinstructions, which can change convergence speed and exchange sizes andin turn require adaptation of the heuristic rules.

This invention is adaptable to other rules for intermediary offergeneration that have properties of (i) generating ultimatelynon-increasing offers for a commodity while (ii) not being merelylimited to the amounts in the e-agents' counter-offers. In particular,the variable demands determined by the intermediary can depend onseveral prior intermediary offers and several prior e-agentcounter-offers. Further, the demands can be chosen to be greater thanthe least of a determined number of prior counter-offers but less thanthe maximum of another determined number of prior offers.

5.2. Offer and Counter-Offer Generation

In this embodiment, the intermediary and e-agents exchange offer andcounter-offer messages, according to the preferred protocol, describedabove, to arrive at a satisfactory exchange. As indicated, anintermediary allocates commodities among the e-agents in a mannersatisfactory to the joint goals of the participants. Each e-agentresponds to offers from an intermediary with counter offers, generatedaccording to its objectives. This section presents methods for theintermediary and an e-agent to generate offers and counter offers.

An offer message of the preferred embodiment includes the followingdata:

1. Commodity names; and

2. For each commodity, the amount of that commodity that is currentlyoffered by the intermediary for sale or for purchase.

Similarly, a counter-offer message includes:

1. Commodity names; and

2. For each commodity, the amount of this commodity that the e-agentcurrently is prepared to buy or to sell.

5.2.1. E-Agent Counter-Offer Generation

An e-agent of the preferred embodiment is a computer process that actsaccording to the objectives of its principle. As indicated, at the startof the electronic intermediated exchange, an e-agent sends to theintermediary an opening message listing all the commodities of interestto its principle and the maximum amounts of each commodity to buy orsell at the exchange. Subsequently, the e-agent responds to offermessages from the intermediary with counter-offers as discussed above.This subsection describes two exemplary embodiments of counter offergeneration: (1) a method primarily suitable for financial commoditiesbased on portfolio theory, and (2) a method primarily suitable for othertypes of commodities in general, based on general rules.

Method Based on Portfolio Theory

In this embodiment, counter-offer generation is based on portfoliotheory so that a counter-offer is selected from a previous offer bysubstantially maximizing a utility function within the limitsestablished by optional constraints. The utility function, which is afunction of the amounts of commodities in the counter-offer, includesterms representing, among others, such factors as the preference of theparticipant for different commodities, the risk of the variouscommodities, the transaction costs of buying or selling the commodities,and the degree to which certain constraints on commodity holdings may beviolated.

Commodity preferences are numerical weights expressing a participant'sinterest in a given commodity, and can be, for example, theparticipant's expected financial return from owning the commodity. Therisk represents the participant's estimation of the uncertaintiesassociated with owning a particular commodity, and can be, for example,the variance of the expected financial return from owning the commodity.Transaction costs are estimates of the cost of buying or selling in amarket. Finally, a participant can establish certain approximate goalsfor owning groups of commodities, and can allow a certain slack inmeeting these goals. For example, a financial participant may wish todivide holdings among industry groups according to certain percentages.The maximum of the utility function minimizes the extent to which theseallocations are not met.

These components can be gathered into certain strategies, for example,as illustrated in Table 2.

                  TABLE 2    ______________________________________    Utility Function Terms and Strategies              Commodity          Trans.    Strategy  Preference                        Risk     Costs Constraints    ______________________________________    Active with              •   •  •                                       •    risk    Active with no              •            •                                       •    risk    Indexing            •  •                                       •    Characteristics              •                                       •    Opportunity         •        •    Cost    List Completion                    .    ______________________________________

According to a simple strategy called "list completion" (also calledherein "list"), the participant merely instructs its e-agent to makeexchanges from a list of commodities up to certain maximum exchangeamounts. Such a participant may optionally, specify limited types ofconstraints, such as dollar imbalance or tiering constraints. Accordingto a complex strategy called "active with risk", the participantgenerally instructs its e-agent to substantially maximize preferences orexpected return while substantially minimizing risks associated withthese preferences. Optionally, the participant can specify broader typesof additional constraints, such as constraints on transaction costs ofthe exchange, on the deviation of the resulting portfolio from specifiedallocation constraints, and so forth. A less complex strategy is called"active with no risk," and differs from the "active with risk" strategyonly in that risk is not considered by the e-agent, which substantiallymaximizes only expected returns subject to optional constraints.According to the "indexing" strategy a participant instructs its e-agentto substantially minimize the risk, or variance of the return, of aportfolio that represents the difference between the participant'scurrent portfolio and a benchmark portfolio, such as the S&P 500. Aparticipant using "characteristics strategy," for example, may instructits e-agent to invest up to $100M with 40% in identified technologystocks, 40% in automobile stocks, and 20% in banking stocks. Finally, an"opportunity cost" strategy is a more sophisticated form of a listcompletion strategy in which an overall exchange is performed as aseries of sub-exchanges, each sub-exchange in the series being definedso that after its completion the risk of the unexecuted portion of theoverall exchange decreases.

Importantly, Table 2 illustrates that these and other strategies can beimplemented by choosing which terms to include in the utility functionto be substantially maximized by the e-agent and also which constraintslimit this maximization. The details of each strategy are chosen byselecting the actual values of the scalars, vectors, and matricesdefining the utility function terms and the constraints.

The portfolio method of counter-offer generation configures the e-agentbased on parameters passed from its participant. In the following,first, the general e-agent implementation is described, followed,second, by description of how it is parameterized. The subsequentdescription presented in equations 7 through 15 uses variables fromTable 3.

Table 3 below uses vector and matrix variables and vector and matrixnotation to group the commodities together. For example vector hrepresents commodity holdings with components (h₁, h₂, . . . h_(n)),where h_(i) is the amount held of commodity i. In this notation α^(t) ωis a scalar with the value a₁ *w₁ +a₂ *w₂ + . . . +a_(n) *w_(n), wherejuxtaposition represents matrix multiplications and t is the transposeoperator.

                  TABLE 3    ______________________________________    E-agent Variables    Variable     Meaning    ______________________________________    h            Vector of current commodity                 holdings    b            Vector of commodity amounts to buy    s            Vector of commodity amounts to sell    Δω                 Vector of changes in portfolio                 holdings due to amounts bought and                 sold    Δω.sup.1 ; Δω.sup.u                 Vectors with positive elements                 which give the upper and lower                 bounds on the amounts of each                 commodity to buy or to sell    ω      Vector of commodity holdings after                 buying and selling the amounts                 indicated in vectors b and s    ω.sup.1 ; ω.sup.u                 Vectors with positive elements                 which give the upper and lower                 bounds on the amounts of each                 commodity to have in a final                 portfolio    α      Vector indicating the expected                 return, or other numerical                 preference measure, for each                 commodity    Σ      Matrix giving the covariance of the                 expected returns, or other                 numerical risk measure, for all                 pairs of commodities, i.e. the risk                 model    B            Vector of the holdings of a                 benchmark portfolio against which                 risk is judged; if set to 0, then                 risk is judged absolutely without                 reference to any benchmark    γ      Scalar measuring the aversion to                 risk; if set to 0, risk is ignored                 in generating counter-offers    σ.sup.u                 Scalar which limits the maximum                 value of the risk measure    T (Δω)                 Separable model of transaction                 costs giving the transaction costs                 for the net buys and sells                 indicated by Δω    δ      Scalar measuring the aversion to                 transaction costs; if set to 0,                 transation costs are ignored in                 generating counter-offers    C            Matrix providing linear constraints                 on the commodities in a final                 portfolio; an exemplary such matrix                 groups financial commodities into                 industry sectors    c.sup.1 ; c.sup.u                 Vectors providing lower and upper                 bounds, respectively, for the                 linear constraints on the final                 portfolio    φ        Vector measuring the aversion to                 missing each linear constraint                 bound; if an element is set to 0,                 errors in that bound are ignored in                 the utility function and the                 constraint is left rigid    S.sup.1 ; S.sup.u                 Vectors with positive elements                 measuring the amount by which the                 linear constraint bounds are missed                 on the low-side and up-side,                 respectively; also known as slack                 variables    D            Matrix providing linear constraints                 on the changes in portfolio                 holdings; an exemplary such matrix                 includes commodity prices and                 measures the dollar imbalance of                 all the exchanges of the counter                 offer    d.sup.1 ; d.sup.u                 Vectors providing lower and upper                 bounds, respectively, for the                 linear constraints on the changes                 in portfolio holdings    ______________________________________

Vectors "b" and "s", the amounts of each commodity to buy or sell, aredetermined by finding the maximum (or approximate maximum) of theutility function. Their difference is the change in the portfolioholdings, Δω.

    Δω=b-s                                         (8)

Equation 9 below specifies upper and lower bounding constraints on thechanges in portfolio holdings.

    Δω.sup.l ≦Δω≦Δω.sup.u(9)

For a particular commodity, the meaning of equation 9 depends on whetherthe commodity can be bought, sold, or both. In the case of a commoditywhich is only bought, Δω^(u) specifies the maximum amount to buy, andΔω^(l) specifies an optional minimum amount that must be met for anyexchange. Conversely, in the case of a commodity which is only sold,Δω^(l) specifies the maximum amount to sell, and Δω^(u) specifies anoptional minimum amount that must be met for any exchange. Finally, inthe case of a commodity that can be either bought or sold depending onthe course of the negotiated exchange, Δω^(u) specifies the maximumamount to buy, and Δω^(l) specifies the maximum amount to sell. In thislatter case, two additional parameters are optionally provided tospecify minimum threshold amounts to buy and sell that must be met forany exchange.

These constraints, Δω^(u) and Δω^(l), change during the intermediatedexchange negotiation in accordance with the previously describedprotocol. Before the intermediated exchange, the participant instructsits e-agent with the maximum amounts of commodities to buy or sell. Theparticipant can also optionally specify the minimum amount to buy orsell so that if this minimum is not met no exchange of that commodity ismade. The e-agent transmits in its opening message these upper and lowerbounds on the amounts to buy or sell to the intermediary for its use ininitial offer generation.

In subsequent negotiation rounds, the e-agent generates counter-offersby selecting amounts to buy or sell from the intermediary's precedingoffers. Thus, at each stage of the negotiation, the upper bound inequation 9, that is Δω^(u), Δω^(l), or both as is appropriate, is set tothe amounts offered in the immediately preceding offer from theintermediary. Accordingly, the upper bound limiting the exchangedamounts, and thus the decision variables in equation 9, vary during theintermediated negotiation.

In equation 10, ω is a vector containing the amounts of commodities thatwill be in the portfolio if an intermediary accepts the e-agent'scounter-offer.

    ω=Δω+h                                   (10)

The amounts in the portfolio, ω, are the current holdings of theportfolio, h, plus the changes in the portfolio, Δω. A participant canalso optionally specify limits on the total amounts of each commodity ina portfolio by specifying upper and lower bounds, ω^(u) and ω^(l), inequation 11 that limit the possible values of ω.

    ω.sup.l ≦ω≦ω.sup.u         (11)

A preferred utility function, U_(A), is expressed in terms of ω and Δω,and thus in terms of the decision variables b and s, in equation 12below.

    U.sub.A =α.sup.t ω-γ(ω-B).sup.t Σ(ω-B)-δT(Δω)-φ.sup.t (S.sup.u +S.sup.l)(12)

The first term in equation 12 represents the preference, or expectedreturn, of the proposed portfolio, and is a sum of the amount of eachcommodity in the proposed portfolio times its numeric preference factor,or expected return. The preference factors for all the commodities aregathered into the elements of vector α. Other forms of utility functionsadaptable to this invention are apparent to those of skill in the art.

The remaining three terms of the utility function above represent theparticipant's aversions to risk, to transaction costs, and to constraintslack, respectively. The second term, representing aversion to risk, istypically the variance of the preference or expected return with respectto an optional benchmark portfolio, represented as vector B of benchmarkcommodity amounts. If this benchmark portfolio is specified, the risk ofa proposed portfolio will be zero if the proposed portfolio is the sameas the benchmark portfolio. If the benchmark portfolio is not specified,B is 0, and the second term measures the absolute amount of risk in theproposed portfolio. The matrix Σ has elements which are the covarianceof the commodity preferences or return and represents risk inmean-variance portfolio theory. The factor γ is a weighting factorrepresenting the participant's overall aversion to risk.

The third term models transaction costs as a function of the amounts ofcommodity exchange, Δω. The transaction cost model, T, is preferablyseparable, in that the cost for exchanging a particular commodity isindependent of the amounts of other commodities exchanged. T need not belinear in the amounts of commodities exchanged, and can, for example,represent decreasing costs with increasing amounts of commoditiesexchanged. The factor δ represents a participant's overall aversion totransaction costs.

The fourth term represents the participant's aversion to constraintslack, or in other words, constraint violation. This factor is a sum ofproducts, each product including a term from vector φ representing aparticipant's aversion to the slack in that particular constraintmultiplied by the amount by which that constraint is violated, either onthe low side, represented by S^(u), or the high side, represented byS^(l).

In this utility function all the terms are preferably positive.Therefore, when this function is substantially maximized, the expectedpreference or return of the proposed portfolio is substantiallymaximized, while simultaneously the risk, the transaction costs, and theconstraint violation slack are substantially minimized according to thespecified aversions.

The utility function of equation 12 is substantially maximized withinthe limits of constraints such as specified by equations 13-16.Equations 13 and 14 illustrate financial asset allocation constraintsthat limit the amounts of particular classes of commodities in a finalportfolio.

    c.sup.l ≦Cω+S.sup.l -S.sup.u ≦c.sup.u  (13)

    0≦S.sup.l, S.sup.u                                  (14)

Such classes can be, for example, industry groupings, e.g., utility,technology, or cyclical stocks. Each row of matrix C adds portfolioholdings of commodities of a particular allocation class. Vectors c^(l)and c^(u) represent the minimum and maximum amounts, respectively, ofcommodities in the groups defined by matrix C. Slack variables S^(l) andS^(u), having positive elements according to equation 14, record theamount by which the commodity allocation constraints are violated on thelow side and on the high side, respectively.

Equation 15 constrains the risk in proposed portfolio, ω, compared to anoptional benchmark represented by B. This constraint limits the totalrelative risk, or total absolute risk where B is 0, to less than amaximum quantity σ^(u).

    (ω-B).sup.t Σ(ω-B)≦σ.sup.u  (15)

Finally, equation 16 represents additional constraints on the amounts ofcommodities exchanged, Δω.

    d.sup.l ≦DΔω≦d.sup.u             (16)

In the case where matrix D represents the prices of commodities, thisconstraint limits the total dollar imbalance of the total commodityexchange represented by Δω to be between a lower bound, d^(l), and anupper bound, d^(u). This constraint may be useful for limiting cashexposure during a particular intermediated exchange.

The framework described above implements the previously describedportfolio strategies by merely setting certain variables to 0 or 1 asprovided in Table 4. Absence of a parameter limitation is indicated byan empty box in this table. For example, the "active with risk" strategyallows all the parameters to be set freely by a participant. On theother hand, the "active with no risk" strategy requires that the riskaversion parameter, γ, be set to 0, leaving the other parameters to befreely set. The simple "list" strategy requires that all the preferenceweights, α, be set to 1 with all the remaining parameters of the utilityfunction set to 0. For this strategy, substantially maximizing theutility function merely maximizes the total amounts in the proposedportfolio, ω, as the utility function in this strategy merely reduces toa sum of the amounts of commodities in a proposed portfolio. Thismaximum is limited by any optional constraints specified according toequations 9, 11, 13, 15 and 16.

Therefore, to select and parameterize a strategy, participants generallymake some or all of the following selections for each order submitted tothe intermediated exchange:

1. Specify commodities to buy and sell and the maximum, and optionallythe minimum, amounts to be exchanged (vectors Δω^(l), Δω^(u), ω^(l), andω^(u));

2. Specify commodity preference rankings by buy or sell side (vector α);

3. Select risk model, benchmark portfolio, if any, and specify riskaversion and/or risk limit (matrix Σ, vector B, scalar γ, and scalarσ^(u), respectively);

4. Select transaction cost model and specify cost aversion (functionT(Δω), scalar δ, and the parameters of equations 17-20);

5. Specify other constraints, such as cash imbalance constraints (matrixD, vectors d^(u) and d^(l)).

In the preferred embodiment, a participant makes these selections usinga set of screen displays that facilitate entry of parameters or choicesaccording to individual strategies.

                  TABLE 4    ______________________________________    Strategy Option Implementation    Strategy     α   γ                                 δ h   φ    ______________________________________    Active with risk    Active with no risk    0    Indexing     1    Characteristics                 1         0    Opportunity Cost                 1         0     0           0    List         1         0     0       0   0    ______________________________________

Various alternative utility functions and constraints may be used invarious embodiments of the invention. Equations 17-20 illustrate onesuch alternative. These equations, include additional terms representingthe transactions cost in the intermediated exchange compared to thetransaction costs in other markets or exchanges. Here, vectors b_(i) ands_(i) represent the amounts to buy or sell, respectively, in thisintermediated exchange and vectors b_(m) and s_(m) represent the amountsto buy or sell in other markets or exchanges.

    Δω.sub.i =b.sub.i -s.sub.i                     (17)

    Δω.sub.m =b.sub.m -s.sub.m                     (18)

    Δω=Δω.sub.i +Δω.sub.m  (19)

Equations 17 and 18 give the net amounts exchanged in this intermediatedexchange and in other markets. According to equation 19, the totalamount of commodities exchanged, Δω, equals the sum of the net amountsexchanged in the intermediated exchange of this invention and the netamounts exchanged in other markets. The transaction cost term in theutility function, the fourth term in U_(A) of the equation 12 isreplaced according to equation 20.

    δT(Δω)=δ.sub.i T(Δω.sub.i)+δ.sub.m T(Δω.sub.m)(20)

The overall separable transaction cost model is the sum of two differentseparable transaction cost models: (1) a function of the amountsexchanged that uses the system of this invention, and (2) a function ofthe amounts exchanged in other markets. Sophisticated participants canuse this alternative approach to make trade-offs between the cost ofportfolio management using the system of invention and the cost ofmanagement in other markets.

Other alternative utility function and alternative portfolio techniquesadaptable to this invention can be developed by those of skill in theart based on this disclosure. For example, additional constraints can beadded, or the linear and quadratic terms for the commodity preferencesand risk aversion of Equation 9 can be replaced by more generalfunctions. Also frameworks other than the mean-variance, risk-rewardmodel can be used by e-agents.

Method Based on Rules

Alternatively, an e-agent can use rules to generate counter-offers inresponse to an intermediary's offers. These rules, provided to thee-agent by the participant, preferably, are stated using typicalprogramming language syntax, such as "if-then-else" statements, "for"statements, "while" statements, "case" statements, and so forth. Thesestatements may include Boolean tests applied to the commodity amounts inan offer and executable portions that generate an e-agent'scounter-offer. In one implementation, these statements are executed by astatement or a rule interpreter of the e-agent process, while in anotherimplementation, these rules could be compiled into a module which issimply called from the e-agent process.

The following set of rules illustrate the rule-based approach.

    ______________________________________    BEGIN    IF {    (Shares of IBM Stock offered for sale >= 1000            shares) & (pork-bellies offered for purchase >=            10 units) }    THEN {    (counter-offer to buy IBM stock <= 100,000 shares)    & (and counter-offer to sell an equivalent dollar    amount of pork-bellies)    };    IF {    grapefruit is offered for sale at less than $1            per pound }    THEN {    counter-offer to buy grapefruit <= 10 pounds    ELSE IF {bananas are offered for sale at less than $2    per pound }    THEN    counter-offer to buy bananas <= 4 pounds    }    ELSE IF { figs are offered for purchase at greater than    $3 per pound }    THEN {    counter-offer to sell figs <= 20 pounds    };    END.    ______________________________________

Based on the above rules, an e-agent would generate an opening messagewith the following contents: IBM stock can be bought in quantitiesbetween 1,000 and 100,000 shares; pork bellies can be sold in quantitiesbetween 10 units and an amount dollar equivalent to 100,000 shares ofIBM stock; grapefruit can be bought in amounts of less than 10 lbs.;bananas can be bought in amounts of less than 4 lbs.; figs can be soldin amounts less than 20 lbs. After this opening, the e-agent wouldgenerate counter-offers from intermediary offers by applying these rulesto the offers. For example, an intermediary offer could include thefollowing: the sale of 10,000 shares of IBM stock; the purchase of 1,000pork bellies; the sale of 20 lbs. of grapefruit at $2 per lb.; the saleof 10 lbs. of bananas at $1 per lb.; and the purchase of 40 lbs. of figsat $4 per lb. Applying the above rules to such an offer, an e-agentwould offer to buy an amount of IBM stock dollar-equivalent to 1,000pork bellies, since the minimum requirements of the first rule are metby the offer of IBM stock to sell and pork bellies to purchase. Nograpefruit is purchased, since it is offered at a price greater than $1per lb. According to the first "else" alternative of this "if"statement, 4 lbs. of bananas are bought since they are offered at lessthan $2 per lb. This successful purchase terminates the "if" statementwithout further consideration of the offer to purchase figs. As aresult, the e-agent would sell 1,000 pork bellies, purchase a dollarequivalent amount of IBM stock, and purchase 4 lbs. of bananas.

5.2.2. Offer Generation

As described, the intermediary and the e-agents exchange messages inorder to arrive at a satisfactory intermediated exchange. The e-agentsdo not communicate directly with each other, and are not aware of eachother's identity or existence. In the preferred embodiment for financialcommodities, the intermediary seeks to allocate commodities in order tosubstantially maximize in a fair manner the total amount of allcommodities exchanged. This commodity allocation can also be subject tocertain optional constraints that may be implemented in the intermediarydue to market requirements, secrecy requirements, efficiencyrequirements, and so forth.

Since many commodities are directly exchanged in whole units, theintermediary preferably does not generate offers to e-agents forfractional amounts of commodities. For example, financial marketstypically exchange shares of common stock in units of 100. Such a commonconstraint can be implemented in the intermediary. Another type ofconstraint for intermediary implementation is known as "tieringconstraints." In some situations, a participant or a group ofparticipants may be unwilling to trade with other participants or othergroups of participants, while at the same time wishing to maintain theiranonymity. To maintain such secrecy, tiering constraints are preferablyimplemented in the intermediary.

Certain constraints may be implemented in either the e-agents or theintermediary. An example of such constraints are participant minimums onthe number of units of a particular commodity that the participant iswilling to exchange. For example, a participant may wish to exchangeeither 5,000 units or more up to some specified maximum or nothing atall. To substantially maximize the amounts of commodities eventuallyexchanged and to substantially minimize message generation, such e-agentminimums may be implemented in the intermediary. Other appropriateconstraints can also be implemented in the intermediary. For example,limited e-agents, such as e-agents for list-strategy participants, canhave their constraints implemented as part of offer generation in orderthat any generated offers are automatically acceptable to such limitede-agents, and can be accepted with an identical counter-offer withoutfurther rounds of negotiation.

The objectives of substantially maximizing the total amount ofcommodities exchanged and the fairness of their allocation among thee-agents often conflict. This conflict can be resolved in various ways.In the preferred embodiment that deals with financial commodities, theintermediary generates each offer in a manner that substantiallymaximizes the tradeoff between the total units exchanged and a pro-ratameasure of allocation fairness. In other embodiments, the intermediarycan substantially maximize the amount exchanged while ensuring fairnessonly over the entire intermediated exchange or, perhaps, only overseries of intermediated exchanges. The intermediary may also choose tosubstantially maximize the fairness of allocation at the expense of theamount of exchanged commodities. In all cases, it is preferable that theintermediary act in a manner consistent with the joint interests of allthe participants likely to be present in a given intermediated exchange.

In the preferred embodiment for financial commodities, the intermediarygenerates offers by substantially maximizing a utility function of theamounts of each commodity offered to each of the e-agents. A preferredutility function includes terms representing the amount exchanged andthe fairness of the allocation. The general framework of this utilityfunction and the optional constraints are presented using the variablesin Table 5 below. (For clarity, the subscript, "n," denoting roundnumber of the negotiation, is dropped in this subsection.)

                  TABLE 5    ______________________________________    Intermediary Variables    Variable       Meaning    ______________________________________    B.sup.u.sub.i,j ; S.sup.u.sub.i,j                   Maximum amount of commodity j to                   buy or sell in this exchange,                   respectively, indicated in e-agent                   i's opening message    B.sup.1.sub.i,j ; S.sup.1.sub.i,j                   Minimum amount of commodity j to                   buy or sell in this exchange,                   respectively, indicated in e-agent                   i's opening message; if no minimum                   indicated, 0 is assumed    Y.sup.b.sub.i,j ; Y.sup.s.sub.i,j                   Binary threshold variables are set                   to 1 if the e-agent i receives in                   the current offer its minimum buy                   or sell amounts, respectively, of                   commodity j; otherwise, they are                   set to 0    b.sub.i,j ; s.sub.i,j                   Amount of commodity j to buy or                   sell, respectively, offered to                   e-agent i by the intermediary, as                   determined according to                   intermediary objectives    b.sup.u.sub.i,j ; s.sup.u.sub.i,j                   Maximum aount of commodity j which                   e-agent i can buy or sell according                   to the preferred protocol    d.sup.buy.sub.i,j ; d.sup.sell.sub.i,j                   Current demands, or upper bounds,                   according to the preferred protocol                   on the amount of commodity j which                   e-agent i can buy or sell,                   respectively, at this round of the                   protocol    w.sup.b.sub.i,j ; w.sup.s.sub.i,j                   The relative pro-rata amount of                   commodity j to buy or sell in this                   exchange, respectively, determined                   from the amounts in e-agent i's                   opening message compared to the                   total amounts to buy or sell,                   indicated in all the e-agents                   opening messages    γ        A controllable parameter to adjust                   the tradeoff between fairness and                   amounts allocated    O.sub.1, θ.sub.1                   Tiering-constraint e-agent subsets:                   for each pair of subsets associated                   with a given 1, no e-agent in the                   first subset wishes to trade with                   any e-agent in the second subset    δ.sup.b.sub.i ; δ.sup.s.sub.i                   Optional fairness weights used by                   the intermediary to adjust the                   fairness of the allocation for                   e-agent i in determining buy or                   sell amounts to offer    ______________________________________

The preferred utility function, U_(I) for the intermediary includes twoterms, one term representing the total amount of commodities exchanged,and the second term representing the fairness of the commodityallocation. Since b_(i),j represents the amount of commodity J bought bye-agent I, the total amount of commodities, denoted by A, exchanged isgiven by equation 21. ##EQU1## Because of constraint equation 27, thetotal amounts sold equal the total amounts bought for each commodity.

Commodities are fairly allocated when each e-agent is offered a fairproportion of the total amount of each commodity present in an exchange.This invention is adaptable to numerous ways of determining the fairproportion and the amount of each commodity present. In the preferredembodiment, the fair proportion of a commodity for an e-agent is thate-agent's pro-rata purchase or sales fraction. This fraction is measuredby comparing the demand which the intermediary has assigned to thate-agent in the current round of negotiation to the demands assigned toall the other e-agents in the current round. An e-agent's fairproportion changes during a negotiation, since the demands assigned tothe e-agents change from round to round of the negotiation. In moredetail, since d^(buy) _(i),j is the demand to buy commodity J assignedto e-agent I by the intermediary at the current round of the negotiationof the intermediated exchange, e-agent I's fair proportion of commodityJ to buy is given by equation 22. ##EQU2## Similarly, since d^(sell)_(i),j is the demand to sell commodity J assigned to e-agent I by theintermediary at the current round of the negotiation, e-agent I's fairproportion of commodity J to sell is given by Equation 23. ##EQU3##Further, the preferred total amount of a commodity present in a round ofthe negotiation is the sum of the amounts of this commodity to beoffered in this round to each of the e-agents.

In view of these choices, equation 24 is a preferred measure of theoverall fairness of the commodity allocation among the e-agents.##EQU4## For example, considering the first purchase summation, thedifference between the amount of commodity J that e-agent I is to beoffered, b_(i),j, and e-agent I's fair proportion of commodity J, thatis the pro-rata purchase fraction, w^(b) _(ij), multiplied by the sum ofall amounts of commodity J offered to all of the e-agents, representsthe fairness of the allocation of commodity J for e-agent I's purchase.The greater the difference in these two quantities, the greater is theunfairness, either to e-agent I or to the other e-agents, of e-agent I'sallocation of commodity J. A similar expression represents fairness ofthe allocation of commodity J for e-agent I's sale. The sum, W, of thesemeasures over all commodities and all e-agents is the preferred measureof the fairness of the total allocation. The smaller W, the closer thisallocation is to being perfectly pro-rata. This representation of W as asum of squares is preferred because it facilitates computation of themaximum of the utility function for the intermediary. Other expressionsfor W can also be used. In fact, at the expense of increasedcomputational cost, any monotonicly increasing function of the absolutevalues of these differences can be used as a measure of the allocationfairness.

In certain situations, the preferred fairness measure, which weightsequally all e-agents, fails to result in an allocation satisfactory tothe objectives of all the participants. For example, certainparticipants who have specified large exchange amounts, can receiveproportionately less than they feel is fair in cases where otherparticipants have specified certain constraints, such as dollarimbalance constraints. In such situations, an alternative fairnessmeasure incorporates fairness weights, δ^(b) _(i) and δ^(s) _(i), whichcan give certain e-agents a greater or lesser influence in the fairnessmeasure for purchases or sales according to whether their weights arespecified to be greater or less than 1, respectively. An exemplaryweighted fairness measure is given by equation 25. ##EQU5## Thesefairness weights can be adjusted either during the course of anintermediated exchange or from one intermediated exchange to another, inorder to satisfy the joint fairness requirements of all theparticipants.

Finally, the intermediary utility function is given by Equation 26 asthe difference between the amount exchanged, A, and the measure ofallocation fairness, W, multiplied by an aversion factor, γ.

    U.sub.I =A-γW                                        (26)

This aversion factor controls how seriously an intermediary considersallocation fairness. The greater the value of this aversion factor, themore important role the allocation fairness plays in the intermediary'soverall offer generation.

Preferably, the value of this aversion factor is chosen according to thejoint goals and objectives of the participants and the intermediary in agiven intermediated exchange. In the preferred embodiment, this factoris heuristically chosen by running sample intermediated exchanges withtypical input data or by rerunning past intermediated exchanges usingthe previous instructions provided by the participants along with otherprevious data but with various heuristics. A satisfactory aversionfactor is one which meets the joint goals of the participants and theintermediary for fairness and maximum commodity exchange in these testruns.

The intermediary generates offers by substantially maximizing itsutility function, U_(I), which is a function of the offer amounts,b_(i),j and s_(i),j, subject to certain constraints. One essentialconstraint is that each commodity is completely crossed, that is foreach round of the negotiation the sum of the amounts of each commoditythat the intermediary offers for sale to all the e-agents equals the sumof the amounts of that commodity that the intermediary offers topurchase from all the e-agents. Therefore, no commodity has an excess ora deficit in the exchange. This constraint is expressed in equation 27.##EQU6## A further constraint is that all exchanges occur in multiplesof standard commercial units. For example, for stocks, such a standardunit is 100 shares. Further, the coefficients and bounds must be chosenaccording to the commercial units of the problem. These integerconstraints are expressed in equation 28.

    b.sub.i,j, s.sub.i,j are integer ∀i,j           (28)

In the case of stock, each integer unit represents blocks of 100 shares.

Further constraints are bounds on the commodity amounts that can beexchanged. Equations 29 and 30 express the lower and upper bounds,respectively, on the amounts that e-agent I can buy of commodity J.

    0≦y.sup.b.sub.i,j b.sup.l.sub.i,j ≦b.sub.i,j ∀i,j(29)

    b.sub.i,j ≦y.sup.b.sub.i,j b.sup.u.sub.i,j ∀i,j(30)

Equations 31 and 32 express the lower and upper bounds, respectively, onthe amounts E-agent I can sell of commodity J.

    0≦y.sup.s.sub.i,j s.sup.l.sub.i,j ≦s.sub.i,j ∀i,j(31)

    s.sub.i,j ≦y.sup.s.sub.i,j s.sup.u.sub.i,j ∀i,j(32)

According to equations 29 and 31, the decision variables of the problemare greater than equal to zero. Equation 33 limits the value of thevariables, y^(b) _(i),j and y^(s) _(i),j, called herein "thresholdvariables," to 0 and 1.

    y.sup.b.sub.i,j, y.sup.s.sub.i,j ε{0,1}, ∀i,j(33)

The threshold variables are by default 1, but are set to 0 if an offerbeing computed allocates less than the buy or sell minimum amounts ofcommodity J to e-agent I. These variables, together with equations 29through 32, express the constraint that e-agent I will only buy or sellcommodity J if it can exceed any specified minimum exchangerequirements.

These exchange bounds play a role during a negotiation according to thepreferred protocol for intermediated exchange of this invention. For thefirst offer generated by the intermediary, the upper limit constraintson sales and purchases by each e-agent are set to the limits provided bythat e-agent in its opening message to the intermediary. Also, for thefirst and all subsequent offers, the lower limit constraints on salesand purchases by each e-agent are set to the minimum exchangeconstraints, if any, also specified in e-agents' opening messages.

During subsequent rounds of the negotiation, the upper limit constraintson sales or purchases of each commodity are set to the current demandsfor sales or purchases, respectively, according to the preferrednegotiation protocol, that is:

    b.sup.u.sub.i,j =d.sup.buy.sub.i,j ; s.sup.u.sub.i,j =d.sup.sell.sub.i,j(34)

In this manner, intermediary offers are automatically generatedconsistently with the Intermediary Rule of the preferred protocol. Wherealternative bounds are used in a negotiation protocol, these upper andlower constraints are adjusted accordingly.

As previously discussed, the current demands, or upper bounds, d^(buy)_(i),j and d^(sell) _(i),j, are adjusted during the rounds of thenegotiation according to heuristic rules which balance requirements onnegotiation convergence, exchange amounts, and fairness. Preferably, asthe negotiation proceeds, the current demand for a commodity is chosento progress from its initial amount, the maximum amount of the commodityof interest, towards the amount of the immediately preceding e-agentcounter-offer in a substantially uniform fashion. This preferredheuristic is computed according to equations 35 and 36. ##EQU7## Inthese equations, "n" denotes the number of the current round of thenegotiation; "d_(n) " denotes the current demand; "d_(n-2) " denotes theimmediately preceding demand; and "a_(n-1) " denotes the amount of theimmediately preceding e-agent counter-offer. The constant "K" controlsthe rate by which the current demand approaches the immediately previouscounter-offer. K is preferably approximately 5, or, alternativelybetween 3 and 10. Another embodiment of this heuristic replaces equation35 with equation 37 when n>K. ##EQU8##

According to another heuristic, the current demand in a given round ofnegotiation, for a given commodity and e-agent, is the average of theimmediately preceding intermediary offer and the immediately precedinge-agent counter-offer for that commodity. Thereby, for n<K, the currentdemand is determined according to equation 38. ##EQU9##

Among optional constraints are tiering constraints, which express thedesire of certain e-agents not to exchange with certain other e-agents.According to the tiering constraints, pairs of sets of e-agents, O_(l)and Θ_(l), are defined, such that for each pair of sets, no e-agent inset O_(l) trades with any e-agent in set Θ_(l). Equation 39 expressesthe tiering constraints for purchases of e-agents in set O_(l), byrequiring that all such purchases can be satisfied by sales of e-agentsnot in set Θ_(l). ##EQU10## Equation 40 expresses similarly thisconstraint for sales of e-agents in set O_(l). ##EQU11## Furtheroptional constraints may be included in the intermediary's offergeneration computation, one such being dollar imbalance constraints forthose e-agents. Dollar imbalance constraints are illustrated by equation14.

The problem of substantially maximizing the utility function, U_(I), asdefined by equation 26, according to the described constraints is knownin the art as a "mixed integer-quadratic optimization problem." Itssolution provides the offers that the intermediary sends to eache-agent. As is commonly known in the relevant art, the computationaldemands involved in finding the solutions to such mixedinteger-quadratic problems can be prohibitive, given the currentcapabilities of commercially available processors. Therefore,practitioners skilled in the art often use heuristic methods that do notguarantee that a solution is exactly optimal, but instead provide asolution that is satisfactorily accurate as well as computable in anacceptable time.

In particular, the quadratic form of the fairness term in the utilityfunction, U_(I), certain of the constraints, and the sheer size ofmathematical programs that can be encountered can increase thecomputational demands of the intermediary. Accordingly, the preferredimplementation of the intermediary computation uses one or more, andpreferably all, of the following heuristics to achieve satisfactoryaccuracy within the available computational resources.

First, in view of the size of the problem that the intermediary solvesfor each of the possibly many rounds a successful negotiation mayrequire, the mathematical program of the intermediary is linearized. Thequadratic fairness term W, defined in equation 25, is approximated by apiece-wise linear, convex function according to methods known in the artof mathematical programming. The resulting linear mathematical programof the intermediary can then be modeled as a minimum-cost flow problem.Such a model can be routinely constructed by methods known in the art ofmathematical programming. See, e.g., Papadimitriou et al., 1982,Combinatorial Optimization: Algorithms and Complexity, Prentice-HallInc., which is herein incorporated by reference in its entirety. Ingeneral, an implementation modeled as a minimum-cost flow problem usesless computation per round of the negotiation than an implementationusing linear programming. However, an implementation using linearprogramming has the advantage that a subsequent round of negotiation canuse the solution of the previous round of negotiation for an initialapproximate solution. Therefore, in the preferred implementation, forthe first K rounds of negotiation the intermediary computation ismodeled as a minimum-cost flow problem and, in the subsequent roundswhen the negotiation is closer to convergence, the problem isimplemented using linear programming. The value of K is chosen toachieve an adequately accurate solution within the time bounds on theintermediary. In the preferred implementation, K is set to between 4 and6, preferably approximately 5.

Next, the constraints represented by equations 29-33, which express thate-agent I will only buy or sell security J if the offered amount exceedsminimum exchange requirement b^(l) _(i),j or s^(l) _(i),j, are modeledby the following preferred heuristic. For the first L rounds of thenegotiation, these constraints are disregarded. After the L'th round, ifthe amount, a_(n-1), chosen by the e-agent in a counter-offer is lessthan the specified lower bound, the intermediary sets the demand, d_(n),for the current offer to 0, in order that none of that commodity will beoffered to that e-agent in subsequent rounds of the negotiation. Thevalue of L is chosen to substantially maximize the total amountsexchanged while still satisfying all such e-agent constraints. In thepreferred implementation, K is set to between 4 and 6, preferablyapproximately 5.

Finally, the integer constraints represented by equation 28, whichexpress that the commodities are exchanged in the relevant commercialunits, are modeled by the following preferred heuristic. At each roundof negotiation, first, the intermediary solves the commodity allocationproblem disregarding the integer constraints of equation 28. Second, theintermediary then allocates any fractional commodity units in theresulting solution fairly among the e-agents, so that only integer unitsof commodities are actually exchanged. The allocation of fractionalunits can be done according to many methods. A preferred method for thisallocation proceeds according to the following steps.

1. Ignore integer constraints and solve the problem of substantiallymaximizing the utility function of the intermediary subject toconstraints with continuous variables. Such a solution can be obtainedaccording to methods known in the art, for example, using commerciallyavailable mathematical programming software. This software includesCPLEX™ from CPLEX Optimization Inc. (Incline Village, Nev.) or OSL™ fromIBM Corp. (Poughkeepsie, N.Y.). See, also, Karloff, 1991, LinearProgramming, Birkhauser.

2. For each commodity J, adjust the amounts for each e-agent to buy orsell provided by the continuous solution to integer values according toin the following indented steps:

3. Let T=0.

4. For each e-agent I exchanging commodity J, randomly adjust the amountto buy, b_(i),j, either to .left brkt-bot.b_(i),j .right brkt-bot. (thegreatest integer less that or equal to b_(i),j) or to .leftbrkt-top.b_(i),j .right brkt-top. (the least integer greater than orequal to b_(i),j) with probabilities proportional to (.leftbrkt-top.b_(i),j .right brkt-top.-b_(i),j) or to (b_(i),j -.leftbrkt-bot.b_(i),j .right brkt-bot.), respectively; make a similaradjustment to the amount to sell, s_(i),j ; add the adjusted differenceto T if the order is to buy, or subtract from T if the order is to sell.

5. If T>=1 of if T<=-1, then adjust the order in an opposite manner,that is from .left brkt-bot.b_(i),j .right brkt-bot. to .leftbrkt-top.b_(i),j .right brkt-top. or vice versa, in order to maintainthe value of T to be strictly between -1 and 1.

6. Repeat steps 3, 4, and 5 for each e-agent I interested in commodityJ.

Alternatively, the following process can be used to fairly allocatefractional units.

1. Ignore integer constraints and solve the problem of substantiallymaximizing the utility function of the intermediary subject toconstraints with continuous variables according to the previouslydescribed methods.

2. For each commodity J, adjust the amounts for each e-agent to buyprovided by the continuous solution to integer values according to inthe following indented steps:

3. For each e-agent I exchanging commodity J compute .leftbrkt-bot.b_(i),j .right brkt-bot., the greatest integer less than orequal to b_(i),j. This removes any fractional units from e-agent I.

4. Compute the sum given by equation 41. ##EQU12## This determines thetotal fractional units of asset J taken from all e-agents. Then truncateB_(j) to .left brkt-bot.B_(j) .right brkt-bot..

5. Reallocate the truncated B_(j) fractional units back to the e-agentsone unit at a time according to the following steps:

6. While B_(j) >0 do:

7. Rank the e-agents in order by their:

share of the allocation (ascending);

slack in cash balance constraint (descending),

units below minimum units (ascending).

8. Assign one unit to the e-agent ranked highest in step 7. Break anyranking deadlocks randomly.

9. B_(j) =B_(j) -1

10. Repeat steps 1 and 2 for the continuous sell variables.

5.3. An Embodiment for Exchange of Financial Commodities

As discussed, this invention is particularly adapted to the exchange offinancial commodities, and in this section the preferred implementationadapted to this exchange is described. Financial commodities includesuch intangibles as stocks and bonds, as well as contracts for thefuture exchange of tangible or intangible commodities, known as options.Preferably, these commodities are traded in financial markets duringwhich publicly available bid and ask prices are established. Financialcommodities are often identified by a number selected by the Committeeof Uniform Security Identification (the "CUSIP number"), or by anexchange trading symbol, and in the following the word "symbol" is oftenused synonymously with financial commodity.

In this embodiment, the invention includes an Order-Manager system(hereinafter also referred to as an "OM" system). This system makesservices for the electronic intermediated exchange of financialcommodities available to, typically, remote participants over networkinterconnections. This system accepts commodity exchange orders fromparticipants, performs intermediated exchanges periodically during theday, either at pre-established times or as instructed by the systemoperator(s), and reports the results of completed exchanges to theparticipants. In the preferred embodiment, preestablished exchanges areconducted four times per day. In general, the OM System according to thepreferred embodiment is structured as a modular collection of computerprocesses that exchange messages. The next subsection describes thegeneral structure and implementation of this set of computer processes.The subsequent subsection describes the message types exchanged and thesoftware architecture of these processes.

5.3.1. The Order-Manager System

FIG. 5 illustrates a preferred implementation of the Order-Managersystem 40, as well as several classes of client systems. The OrderManager includes, client interfaces, system component processes, and theintermediary with e-agents. In this and subsequent sections, a "clientsystem" generally denotes the client portion of a client-server computersystem. More particularly, it denotes a computer system used by aparticipant to access the OM system services.

Client systems for the participant access are preferably grouped intoclasses which have similar characteristics, such as similar ordercomplexity, similar OM system access performance, similar OM systemaccess authority, and so forth. These classes include general clients79, limited clients 80, trading workstations 81, and further clienttypes A 83 and types B 84. These client computer systems run participantinterface software, herein called "client interactive" software, adaptedto particular client types and constructed according to the userinterface specification appropriate to the particular client system. Inmore detail, general client systems 79 are for those participants whorequire the most general processing capabilities from their e-agents. Asdescribed previously, such processing capabilities include selectingcommodities according to methods such as finding a constrained extremumof an objective function of commodity amounts or applying rules tocommodity amounts. Therefore, the client interactive software forgeneral clients is adapted to the entry or receipt of a large number ofvariables describing these capabilities, such as the variablesidentified in Table 3. Accordingly, this software includes screens forentry and display of these variables and the interface is preferablyinteractive. In other embodiments, this software can be non-interactive,for example, by being adapted to batch data entry by a participant.

On the other hand, limited client systems 80 are for participants withsimpler exchange requirements. A type of limited client, the "listcompletion" client of Table 2, merely accepts any offer from theintermediary which includes commodities of interest and meets limitedtypes of constraints. Such a client is specified by a more limited setof variables, including a list of commodities sought in an exchange,maximum and, optionally, minimum amounts of each commodity sought, andconstraints such as tiering, dollar constraints, and price limitconstraints. As described subsequently, limited clients may also beprocessed efficiently by the intermediary without creating separatee-agents. Limited clients may optionally be processed by general clientsystems and general client interface processes, since they can bespecified by variables which are a special cases of those for generalclients.

Other client systems types include trading computer workstations 81 andglue client computer systems 82. Trading workstation systems 81 are aspecial class of client system designed for operators and administratorsof the OM system, and not for participants. One or more of the tradingworkstations can have administrator-level authority for their users tocontrol access to the OM System by other client systems, initiate,monitor, and control intermediated exchanges, and perform other generalsystem control and configuration functions. Other trading workstationsmay be used by operators who accept orders for intermediated exchangesfrom participants without client systems.

Glue client systems 82, also called herein the "glue," are more complexclients of the OM system. Although they are client systems of the OMsystem 40, they are in turn server systems to attached client systems ofparticipants of various types, such as type A clients 83 and type Bclients 84 attached by links 89. Client systems attached to glueclients, or to the glue, execute more capable client interactivesoftware, which can direct financial commodity requests to varioustrading systems other than the OM system 40. Therefore, in addition tobeing linked to the OM system 40, glue clients 82 are also attached toother exchange systems 97, such as systems for trading in the NYSE orthe National Market System of the NASD, and route exchange requests fromtheir own attached client systems to the correct exchange system. As arouter connected to the OM system, the glue clients preferably multiplexthe OM system requests of their own attached clients over one link, suchas link 90.

Finally, certain clients are specialized for administrative andoperations functions. Such functions include participant commissionbilling, end-of-day clearance of completed exchanges, and so forth. Theclient interactive software for these client systems is specialized tothese particular operations functions.

Turning now to the client interface processes of the OM, FIG. 5illustrates that each client system directly attached to the OM system40 is linked to an instance of an interface process. Preferably, theseinterface computer processes are specialized to the particularrequirements of that class of client systems to which they are linked.Therefore, general clients 79 have general client interface processes85; limited clients 80 have limited client interface processes 94;trading workstations 81 have trading client interface processes 95; andeach glue client 82 has a specialized glue interface process 96.

As each client connects to the OM system, an interface process of thetype specialized for handling that client is preferably spawned. Thisinterface process maintains the connection to the client, and terminatesafter the client disconnects from the system. To decrease computationaloverhead, and thereby to increase performance, an OM system is adaptableto more complex client interface process which are capable ofsimultaneously supporting and maintaining connections to severalclients. A special case of such a more complex client interface processis the "glue" client, which serves all the clients directly connected toa glue server through a single connection that server. Client interfacescan be of two general types: a first type in which a separate interfaceinstance is required for each separate instance of participant access,and a second type in which multiple participants are multiplexed over asingle instance of a client interface. Client interfaces for generalclients 79, limited clients 80, and trading workstations 81 arerepresentative of the first type of client interfaces. For thesesystems, a separate interface process is created for each participantduring that participant's access to the OM system. The clientinteractive software and interface processes of this type are preferablyspecialized to take advantage of this dedicated access link. Participantexchange request information can be held in memory by the interfaceprocess for rapid access in the event of, for example: queries byparticipants; validation of participant's order corrections, deletions,etc.; attaching participant's order details to reports coming from theintermediary before sending them to participants; and so forth.

Client interface processes are preferably implemented to include twoprocessing functions or halves, as illustrated by the two halves of thecircles illustrating client interfaces 85, 94, 95, and 96. Oneprocessing function, for example function 85, is for connecting toclient systems and exchanging messages with participants of theintermediated exchanges through the client interactive software. Thisfunction presents a single communication port for access to the OMsystem and supports communication protocols and message formatsappropriate to each class of client system and client interactivesoftware. Thus, client systems do not need knowledge of the detailedinternal structure of the OM system.

The other interface function, for example function 86, connects to theinternal components of the OM System and exchanges messages with thesecomponents. Thus, the OM internal components do not require knowledge ofits client systems, for example, knowledge of their types, their networkaddresses, their communication protocols, or their client interactivesoftware. Preferably, the internal interface functions of the interfacesrun substantially the same program code.

The two components of the interfaces pass messages between each otherand translate between external formats appropriate for transmission toclients, and internal formats appropriate for transmission to the OMsystem components. Preferably, all messages exchanged between an OMSystem and its clients and also between internal OM System componentsare individually acknowledged and validated to preserve system integrityand client security. Also, other interface implementations can be used.For example, to the extent that limited or other client types arespecial cases of general clients, such client types can also access theOM System through general client interfaces.

Another function of the interface processes relates to orders that aresubmitted with a potential duration of several intermediated exchangesor several days. Some participant strategies and corresponding e-agentsare designed for only a single intermediated exchange. If a participantemploying such a strategy did not receive all desired amounts ofcommodities, then a new order must be constructed by the clientinteractive software and submitted to request any residual amounts.However, other participant strategies and corresponding e-agents permitupdate of a pending order by either removing satisfied commodityrequests or by subtracting partially satisfied commodity amounts. Thepending updated order remains for the next intermediated exchange for upto participant specified maximum number of exchanges or days. Theinterface processes for such participants, without involvement of theclient interactive software, are responsible both for such order updateand for maintaining the order pending according to the participant'sspecifications.

Types of external electronic message exchanged between clients and theOM system include the following: orders, order corrections, exchangereports, queries, query responses, commands, command responses, andbroadcast system messages. In general, these external message typesbegin with a message header exemplified in Table 6.

                  TABLE 6    ______________________________________    Message Header    ______________________________________    Client identifier             E-agent identifier                          Message type                                     Record Count    ______________________________________

The client identifier field uniquely identifies a client to the OMSystem, and can be assigned by, for example, a system operator when aparticular participant is authorized to make use of the OM System. Incases where a client requires an e-agent and an e-agent has already beenassigned, the e-agent identifier or address is included in the messageheader in order to make message delivery internal in the OM system moreefficient. The message type field indicates the type of the message, andthe record count field specifies the length or number of sub-recordspresent in this particular message.

Order messages include basic and optional information and can beformatted into a variety of alternative formats. In the preferredembodiment a client presents basic portfolio information, that isidentification of the financial commodities to be exchanged along withthe maximum amounts of each commodity to be exchanged. Basic portfoliomessages have multiple records of a format exemplified in Table 7.

                  TABLE 7    ______________________________________    Portfolio Detail Record Format    ______________________________________    Asset identifier               Price  Buy/Sell   Minimum                                        Maximum                                 trade size                                        trade size    ______________________________________

The fields of this message are described in the following table 8.

                  TABLE 8    ______________________________________    Portfolio Message Fields             Data    Field Name             Type    Description  Values    ______________________________________    Asset    Char.   Unique identifier                                  Any valid string,    Identifier             (24)    for asset across                                  e.g. a symbol or                     participants.                                  CUSIP number.    Price    Float   For certain  Any non-negative                     participants, a                                  number.                     dollar ceiling                     (for a buyer) or a                     dollar minimum                     (for a seller)                     beyond which no                     asset should be                     exchanged.    Buy/Sell Char.   Flag to indicate                                  B: Asset is bid             (1)     whether asset is                                  for purchase.                     being offered for                                  S: Asset is                     sale or bid for                                  offered for sale.                     purchase.    Minimum  Float   Minimum units of                                  Any non-negative    Trade Size       asset required by                                  number.                     e-agent for a                     purchase or sale.    Maximum  Float   Maximum units of                                  Any non-negative    Trade Size       asset that e-agent                                  number.                     will buy or sell.    ______________________________________

For limited clients, certain additional constraints can be presented inoptional order messages, which supplement the minimum trade amountconstraints present in the portfolio message. For example, cashimbalance constraints can be presented as a pair of floating pointnumbers establishing lower and upper bounds for permitted cash balancesafter an exchange. Tiering constraints can be presented as a list ofidentifiers of other clients that this client does not wish to exchangewith. Alternatively, for limited clients, both the base portfolioinformation and the optional constraints can be presented in a singleorder message.

For general clients, an order message of the preferred embodimentnecessarily includes considerable information in addition to the basicportfolio information provided by the limited or list client. First,such information includes an indication of the type of e-agentprocessing requested, such as offer evaluation according either tomean-variance portfolio theory or to procedural rules. In the firstcase, an order message can include numeric parameters sufficient todefine the scalars, vectors, and matrices which specify the objectivefunction and constraints. An exemplary specification is presented inTable 3. In the latter case, an order message can include the proceduralrules specifying e-agent processing. In both cases, either text form orin binary coded form can be used. Also, this additional information canoptionally be combined with the basic portfolio information into asingle, potentially long, order message. Therefore, the client interfacefor a general client is preferably adapted to handle such large ordermessages.

Turning to the additional message types, any parameter supplied in anorder message can be altered by a client prior to initiation of anintermediated exchange by submitting an order-correction message. Anorder-correction message can simply update the particular parametersthat the client wishes changed. In the preferred embodiment, theorder-correction message replaces all parameters previously supplied bya client, whether changed or not.

After an intermediated exchange completes, the OM system returnsexchange reports to each client. These reports include a list ofcommodity identifiers exchanged on behalf of this client, the amountsexchanged, the exchange price, and an indication of whether the exchangewas a buy or a sell. Additionally, in the case of general clients withe-agents performing more complicated processing, the OM system canreturn special data reflecting the details of e-agent processing, forthe participant to check that the e-agent is processing according torequirements, and where this is not the case, to alter parameters orrules to correct processing deficiencies.

Using query messages, a client or participant can query an OM systemconcerning, for example, the status of submitted orders, the time to theorder cutoff for next scheduled intermediated exchange, currentcommodity prices, and so forth. The OM system returns responses toclient queries in the query-response messages. In addition, OM systemoperators, using the trading workstation interactive application, withOM system operator authority, can submit command messages and receivecommand-response messages from the OM system. Exemplary commands includethose for scheduling an intermediated exchange, controlling access to anintermediated exchange, querying exchange orders or the status or theprogress of an intermediated exchange, querying and altering systemconfiguration, querying and altering client authorization, and so forth.A further command provides for running test intermediated exchangesknown as "scenarios." Such test exchanges are advantageous for thepurposes of providing trading workstation users with a prediction of theresults of the next exchange, of verifying that no orders or other datahave been submitted that might cause an exchange to fail, and ofremoving such problematic data, if any. Upon receiving a command toperform such a scenario, the intermediary carries out a completeintermediated exchange using the currently submitted orders, but doesnot store these exchange results in the database. Further, only thetrading workstation clients are informed of the results of a scenario;no reports are sent to the participants or to the tape reportingservice. Finally, broadcast system messages can include messagesindicating the cutoff of orders for the next intermediated exchange, thecommencement of an intermediated exchange, and the completion of theexchange.

In addition to the client interfaces, the Order-Management system hasinterfaces to a source of commodity prices and to systems for publiclyreporting the results of financial exchanges. E-agent strategies of thegeneral clients and optional dollar imbalance or price ceilingconstraints of the limited clients can require a snap-shot ofup-to-the-moment prices of participating commodities just before anintermediated exchange. This invention can use various sources of pricedata that provide on request and in a sufficiently timely fashion such asnap-shot.

However, in the case of financial commodities, currently available are"quote feeds," which either broadcast all quotes/trades of financialcommodity prices or are capable of responding to a price query only forone commodity at a time. To use such a service, this inventionpreferably uses a ticker plant system, which includes ticker plantprogram 101, of FIG. 5, for linking to and monitoring quote feed 78along with database 102 for accumulating commodity prices. The programmonitors the quote feed for price information concerning securities ofinterest in upcoming intermediated exchanges, and maintains a databaseof such prices. At the beginning of an intermediated exchange, thisdatabase provides the up-to-the-moment prices of commoditiesparticipating in the exchange. Since illiquid commodities can appear ona quote feed only a few times each day, the ticker plant must monitorthe entire universe of commodities likely to participate in upcomingexchanges. The ticker plant may also perform certain related functions,such as, discovering missing or bad prices, providing for manual priceupdate, accumulating price statistics, and so forth. Preferably, theprogram of the ticker plant is constructed as a price information serverthat responds to queries with up-to-the-moment prices of multiplecommodities. Thus, a client of the ticker plant is the order-managersystem. Currently, preferred quote feed for the ticker plant is S&PCommstock, Inc. (Harrison, N.Y.).

For financial commodities, regulatory authorities require publicreporting of all exchanges within established and stringent time limits.In order to satisfy such rules, an OM system can connect to publicreporting services and can send to such services in appropriate formatsmessages indicating the results of each intermediated exchange. Suchmessages include asset identifiers along with amounts exchanged andexchange prices. For stocks and those bonds which are traded on the NewYork Stock Exchange ("NYSE"), the American Stock Exchange ("AMEX"), orthe National Market System ("NMS"), such a reporting service isavailable from the Securities Industry Association Automation Corp.("SIAC"). For options, such a reporting service is available from theOptions Pricing Reporting Authority ("OPRA").

FIG. 5 also illustrates a preferred internal structure of order-managersystem 40 of the preferred embodiment, including supervisor subsystem 98with slave-supervisor 100, exchange driver subsystem 73, databasesubsystem 72, and intermediary machine or machines 74, which host thefunctions for performing the intermediated exchange. In general, thesupervisor function together with the database function maintain afault-proof system. The exchange driver function manages message flow toand from the intermediary. The intermediary and its internal functions,which actually perform the intermediated exchange, are described in thenext subsection.

These OM system functions are described sequentially in more detail inthe following paragraphs and subsections after description of thecommunication links between these functions. These links are used forinter-process messages. The supervisor maintains communication links,illustrated by link 99, with all processes in the OM system 40. Eachinstance of a client interface establishes a communication link bothwith the database subsystem 72 and with the exchange driver 73. Forexample, instance 85 of the general client interface establishescommunication link 90 with database function 72 and communication link91 with exchange driver function 73. Thereby, the intermediary itselfneed merely establish two links, link 92 with database subsystem 72 andlink 93 with the exchange driver 73, and need not have knowledge of thenumber, identity, or addresses of any of the client interfaces. Inaddition, the intermediary establishes a link with the ticker plant 101,which acts as a server of up-to-the-moment commodity price information.The intermediary also establishes communication links with external tapereporting service 77, which provides public reporting of completedexchanges.

Supervisor 98 manages a fault-tolerant system environment by monitoringthe OM system processes and restarting any failed processes. It performsthis role in cooperation with database subsystem 72 and on the basis ofprocess conventions used in the OM system. The supervisor 98 establishescommunication links with the OM system processes, such as links 99, andthen periodically queries status of the processes. If a process respondswith an error status or fails to respond at all, the supervisor restartsthe process. If any system process other than an interface processfails, the process itself then recovers its last saved process statefrom the database subsystem 72 and begins processing from that laststate. In the case of a client interface process, in addition thesupervisor indicates to the interface process to which client toconnect. After recovering the saved state of that connection from thedatabase, it reconnects to that client.

All processes in the OM system are structured for fault-recovery. First,all processes periodically save their state in the database subsystem72. Second, the processes, other than interface processes, automaticallyassume that, upon being started, they are starting after a previousfailure, and, accordingly, retrieve from the database saved processstate and begin again with that state. An interface process, however,upon starting, is informed by the supervisor whether it is beingrestarted after a failure, in which case it also retrieves the savedprocess state from the database and begins again with that state as forother processes, or whether it is being started to serve a new client,in which case it begins from an initial state.

Concerning the intermediary in more detail, for recovery purposes,computation of an intermediated exchange is treated as a singleoperation, which either completes or fails as a unit. Therefore,database subsystem 72 stores sufficient state information, such as allinput data, including order and order-correction messages, for anintermediary to be able to reconstruct its initial state just prior tocommencement of an intermediated exchange. If the intermediary or ane-agent fails during the course of an intermediated exchange, all thee-agents and the intermediary are refreshed with the saved stateinformation and the exchange restarted from the beginning upon operatorcommand. Optionally, at operator discretion, an e-agent that failedduring an exchange can be excluded from the restarted intermediatedexchange. If an e-agent fails prior to an exchange, the intermediary cansimply reinvoke the e-agent with its controlling portfolio and otherorder information. Also, the database stores information concerning thecommodities exchanged immediately upon completion of an intermediatedexchange. Therefore, if a system component fails during the reportingprocess after an exchange, the results of the exchange can be retrievedand the reporting process restarted.

Additionally, it is advantageous to test e-agents when they aresubmitted by participants from their client systems. Participants cansubmit parameters, rules, or entire e-agent programs which fail tocorrectly function. Failure of a single e-agent may lead to failure ofan entire intermediated exchange. To avoid this possibility, the OMsystem should preferably test an e-agent for correct functions. This canbe done by presenting each e-agent with a range of offers to verify thatit does not fail and that it returns counter-offers satisfying the AgentRule as discussed above. Unsatisfactory e-agents may be excluded fromthe intermediated exchange and their submitting participants notified.

Supervisor 98 is itself protected from failure by slave-supervisor 100.The slave-supervisor process maintains a copy of the state of thesupervisor and monitors the supervisor by exchanging status messages. Ifthe status messages indicate that supervisor 98 has failed,slave-supervisor 100 takes over the supervisor function of monitoringthe other OM system processes and immediately starts a newslave-supervisor to monitor itself.

The database components of the OM system participate essentially inproviding for a fault-tolerant system by storing copies of all input andoutput messages and records reflecting the up-to-the-moment state of allOM system processes. The database includes database software subsystem72 together with storage means 97. Database subsystem 72 is preferably arelational database system, such as SYBASE version 11 supplied by SYBASEInc. Storage means 97 preferably includes a mixture of solid-state anddisk storage configured, as is known in the relevant art, for sufficientperformance and reliability. Nightly tape backups are performed toprotect from disk failures. In order to store copies of messages sentfrom participants to the OM system, database subsystem 72 establishesseparate communication links to client system interface processes overwhich it receives these message copies. For example, database subsystem72, has established connection 90 with the instance 86 of a generalclient interface. Additionally, the database establishes communicationlink 92 with the intermediary over which it receives results of eachintermediated exchange promptly after exchange completion. If recoveryis needed, as previously explained, copies of this data is supplied tothe failing process in order to reestablish its state.

In the case of intermediated exchanges of financial commodities, inwhich stringent time limits must be met for reporting of exchangeresults, it is advantageous that these results be promptly committed inthe database before reporting. To meet these performance requirements,these results are first stored as a large binary block of unformatteddata representing these results. Upon committing the exchange results,client and public reporting can begin. During reporting, the unformattedbinary block can then be extracted and formatted into a standardrelational row and column format for final storage in the relationaldatabase. Typically, direct formatted storage in the database is tooslow to meet equity reporting requirements.

The database performs certain other functions in the OM system. First,the data about exchange inputs and outputs can be used to tailorintermediary heuristics. As previously described, the intermediary makesuse of certain heuristics to meet the joint exchange goals of theparticipants and the intermediary. By rerunning stored, historicalintermediated exchanges with varied heuristics and comparing results,these heuristics can be tailored. The database subsystem provides suchretrospective data. Second, the database receives certain intermediatedata for an intermediated exchange, including commodity prices usedduring the intermediated exchange and information tracking the processof the intermediary and e-agent computations. Such tracking informationis useful to improve the performance of these computations. The databasealso stores system configuration information. This information includescommunication addresses of the OM computer(s) and software processes, aswell as identities, addresses and authorizations of clients permitted toaccess the OM system. This information is made available to the OMsystem processes during execution and to operators for display andmodification. Hardware and software modularity and configurationflexibility are maintained in order to allow easy addition of newclients and participants, new client types, new e-agent computationalmethods, new hardware machines, new communication pathways, and soforth.

Turning now to the exchange driver 73, it manages order,order-correction, and command messages received from the client systemsdirected to the intermediary 3, and also manages intermediated exchangeresults from the intermediary directed to the client systems. Therefore,first, exchange driver 73 receives input messages from its connectionswith the interface processes and forwards them over its single link 93to the intermediary 3. After passing messages to the intermediary priorto an exchange, it waits for completion of the exchange. After theintermediated exchange completes, exchange driver 73 receives all theexchange results from the intermediary and distributes themappropriately. For each portfolio of each participant, it formatsmessages with the identifiers of the commodities exchanged, the amountsexchanged, and the exchange prices, and sends those messages to theinterface process connected to that participant's client system. Inorder to distribute exchange results, the exchange driver can maintaininformation relating client identifiers with client interface networkaddresses. Also, the exchange driver receives commands directed to theintermediary, such as the command to prepare for an exchange and thecommand to initiate an exchange. Optionally, the exchange driver mayperiodically generate commands to initiate an exchange according to aschedule set by system operators, using the trading workstationinteractive application. In the preferred embodiment, such commandsoriginate from those trading work stations which have operatorauthority. The exchange driver also originates broadcast messages to theparticipants.

In the preferred implementation, each previously described softwarefunction of the order-manager system is implemented as a system processthat may be multi-threaded. Each such process is executed on one of oneor more computers. Communication connections between processes areimplemented either within a computer for collocated processes, or,alternatively, over network interconnections between the OM systemcomputers for remotely located processes. Preferably, all communicationinterconnections are managed according to a common network protocol. Thenumber and capability of OM system computers and the arrangement and thecapacity of network interconnections among these computers are chosenaccording to methods known in the system arts in order to achievedesired performance and throughput targets. In particular, sincefinancial situations are increasingly fluid, it is preferable that anintermediated exchange of financial commodities be completed as fast asis reasonably possible after the command to initiate the exchange isreceived, e.g., preferably within 5-10 seconds. Therefore, the computerson which the intermediary and the e-agents are hosted are preferablycapable of significant integer and floating-point numericalcomputations. Preferred computers for intermediary and e-agent functionsare Sun UltraSparc work stations model 2, or equivalent computers ofequal or greater capacity. These computers run the SunOS operatingsystem and associated operating system components, for examplecommunication drivers. They are interconnected by LANs, preferably anethernet LAN operating at 100 mega-bps. The preferred network protocolis IP with TCP for managing interprocess sessions.

In more detail, for equities, an intermediated exchange must becompleted and publicly reported within 90 secs. This requirement followsfrom National Association of Securities Dealers ("NASD") regulationswhich require that all trades of an equity at its most recent price bereported within 90 secs. Since the intermediated exchange, according tothe preferred embodiment, commences by obtaining the up-to-the-momentprices of financial commodities to be exchanged, it must complete andreport the trade within the 90 sec. window required by NASD. Preferably,the prices actually used are the most recent quote mid-spread prices,that is the average of the most recent bid and most recent asked prices.Further, since transmission time of input prices and output results canrequire from 15 to 30 secs., the actual intermediated exchangecomputation for equities must compute within 60 to 75 secs., at most.Given the method of intermediated exchange computation, necessarycomputers are chosen to have the capability to perform the necessarycomputation within approximately 1 minute or less. Further, the methodof intermediated computation, itself, is chosen so that it is possibleto meet this requirement. For example, the rounding heuristic foraccommodating integer constraints provides computational simplicity inorder to meet this NASD window. Also, the current demand heuristicprovides sufficiently rapid convergence.

Other order-manager system architectures can be used. For example, in analternative in order to improve intermediary reliability by limitingexternal access, the ticker plant price server can be linked to theexchange driver instead of to the intermediary. Similarly, the tapereporting external interface can be linked to the exchange driver. In adifferent embodiment, the intermediary and the exchange driver may becombined into one process; the intermediary may establish directconnections with client interfaces in order to obtain orders and returnexchange results. Also, as noted, the intermediary machine 74 can beimplemented using several machines. In this case, the systemconfiguration component of database 72 would contain the addresses andcommunication links between such machines, as well as the machine foreach e-agent of each particular participant.

5.3.2. Intermediary Message Protocol and Process Structure

The functions hosted on the intermediary machine(s) are described indetail in this subsection. Described first are the preferredimplementation, the general functions, and the message protocol of theintermediary and e-agents. Described second are the processes accordingto which the intermediary and e-agents function.

FIG. 6 illustrates in more detail an implementation of the intermediarymachine(s) 74 of FIG. 5. The intermediary machine or machines generallyhosts intermediary process 3 and e-agent processes 1. Optionally, anexchange with only limited clients has no e-agent processes. Theintermediary machine is preferably a plurality of machines connected bya communication network, such as a LAN with the system processesdistributed across the machines in order to equalize processing load andthereby achieve increased performance, as is known in the art. Further,as previously described, certain e-agent processes can be locatedremotely from the OM system, being hosted on machines controlled byparticular participants and connected to the intermediary bytelecommunication links. Alternatively, where one machine has asufficient computing capacity to meet the computing demands of all theseprocesses, they are collocated on that single machine for reducedcommunication overhead. Such a single machine can be either a verycapable uni-processor or a multi-processor. In the latter case, the samesoftware architecture can be used with each e-agent assigned to its ownprocessor. An alternative architecture for a multi-processor machineimplements the intermediary and the e-agents as separate threads of asingle process. A further alternative for a very capable uni-processorimplements the intermediary and the e-agents as parts of onesingle-threaded program linked by procedure calls.

As further illustrated in FIG. 6, intermediary process 3 includes threeprincipal functions: allocation function 114, local data area function113, and communications interface function 112. Allocation function 114performs the actual computations necessary to generate offers toe-agents according to the preferred protocols for intermediatedexchange. In the preferred embodiment, and especially for financialcommodities, this computation is performed according to the methods ofSection 5.2.2, which depends on the solution of a mixedinteger-quadratic numerical optimization problem limited by describedconstraints. This problem can be solved by methods known in the art andavailable as software packages from commercial suppliers as discussedbefore.

Local data area function 113 is responsible for storing and retrievingmost shared data used by the intermediary. It includes functions ormethods to store and retrieve shared data objects, thereby providing aninterface between communications interface function 112 and allocationfunction 114. Before the commencement of an exchange, the communicationinterface stores in the local data area, information generally necessaryfor an intermediated exchange, such as up-to-the-moment commodityprices. Also stored in the local data area 113 are the exchangerequirements and objectives of certain limited function clients, such aslist clients. These exchange requirements include their portfolio orderand correction messages and any constraint requirements, such as dollarimbalance or tiering constraints. After an exchange, the communicationsinterface 112 distributes the exchange results, which have been storedin local data area function 113 by the allocation function 114, todatabase 72, to exchange driver 73, and to tape reporting service 77.First, the exchange results, stored in an unformatted binaryrepresentation in the local data area, are quickly committed in thedatabase in this binary form. These unformatted results are intelligibleto the intermediary but are not formatted into database fields. Afterdatabase commitment, the results are distributed to the other elements,optionally being translated into text form. For certain clientinteractive software that is capable of formatting the binary results notext translation is necessary. When recovering from a failure duringexchange reporting after a completed exchange, the just completedexchange results are retrieved into local data area function 113 fromdatabase function 72 in order to restart the reporting process.

During the actual intermediated exchange, allocation function 114 firstretrieves the previously described stored data, and constructs anin-memory representation of the mathematical programming ("MP")optimization problem that is solved to generate intermediary offers. Togenerate an offer, the intermediary passes this representation to MPlibrary routines, which actually solve the optimization problem. Thesolution result is then updated in local data area function 113, inorder that the exchange results are immediately available fordistribution in case the e-agents accept the intermediary offers. Ifthey do not accept their offers, the in-memory structures are updatedwith the e-agent counter-offers and the next round of the electronicnegotiation proceeds. The in-memory MP representation is constructed intwo phases in order that the intermediary is not committed to anyparticular set of MP library routines. In a first phase a generalrepresentation of the problem is constructed. In a second phase, aspecific representation is constructed directed to the particularlibrary routines currently used. For example, in the preferred case ofusing CPLEX™ derived library routines, this second phase constructs arepresentation adapted to use by the CPLEX™ routines.

Finally, communications interface function 112 provides functions forall external communications needed by intermediary 3. Therefore, itcommunicates with exchange driver 73, which in turn communicates withall instances of client system interfaces in the OM system, with thedatabase 72 for reporting and recovery purposes, with the ticker plant101 for obtaining price information, and with tape reporting service 77for publicly reporting results of an intermediated exchange. Duringnormal exchange processing, the communications interface function 112receives input data from the exchange driver 73, which it distributes asappropriate to the local data area 113 or the allocation function 114.During recovery processing, the communications interface function 112retrieves data from the database function 72 either to be prepared toexecute an exchange following a system failure that occurred while notrunning the actual intermediated exchange, to restart an intermediatedexchange following a failure of the actual exchange, or to restart thereporting process.

The intermediary is preferably implemented as a single processconstructed from the three functional modules described. In summary, thecommunications interface handles all inter-process communication of theintermediary. The local data area separates the handling of the complexdata required by the intermediary from the other intermediary functions.For sufficient performance, all this local data is kept in actualmachine memory. Finally, the allocation function computes the actualintermediated exchange. These functional modules communicate by methodor procedure calls.

The preferred implementation of the intermediary 3 and of e-agents 1uses object-based technology. According to such an implementation eachof the principle intermediary functions is an instance of an objectcontaining private data and presenting methods necessary to carry outthe particular functions required. In a preferred object-orientedimplementation, messages between intermediary functions on communicationlinks 121 and between the intermediary and e-agents 1 acrosscommunication links 120 contain data for invoking methods presented bythese objects. For example, the local data area function 113 maintainsintermediary data shared among the principal functions and presentsmethods to store and retrieve this data, among others. Thecommunications interface function 112 presents methods to communicatewith the described externally connected processes, among others. Theallocation function 114 presents a single method to run an intermediatedexchange, which performs offer generation for each negotiation stage ofan exchange and places the offer results in the local data area. Thepreferred language for such an implementation is C++.

In particular, the numerical optimization calculations required by theallocation function 114 constructed according to the preferredembodiment, can be inherited from computational classes built fromcommercially available numerical optimization packages suitable forsolving mixed integer or quadratic programming problems. A preferredsuch package is CPLEX™ from CPLEX optimization, Inc. (Incline Village,Nev.). These inherited computational functions are preferablymulti-threaded and therefore, capable of executing in parallel on amulti-processor computer system for improved response time. Such amulti-processor computer can be either a shared-memory or amessage-passing multi-processor system as are currently commerciallyavailable.

A less preferred implementation of the functions of the intermediary 3and e-agents 1 is according to any programming technology which providesfor process and function coordination by message passing, while notnecessarily providing for encapsulation or inheritance.

To improve performance, any implementation of the intermediary and thee-agents should keep as much data as possible in memory. At least thedata stored in the local data area as well as any data needed by the MPoptimization calculations should be memory-resident. Further, it ispreferable that an OM system, together with its client systems and theirparticular client interactive software, keep all the data for aparticular intermediated exchange in memory. This provides for rapidcomputation of an exchange and for rapid reporting of exchange results.

Before turning to a detailed description of the message flow in theintermediary machine(s) of the order-manager system, optimization ofthis message flow in order to take advantage of certain properties oflimited, or list, clients or participants is discussed. Intermediatedexchanges with certain limited clients can be treated separately fromthe exchanges with more general clients in order to decreasecomputational requirements and increase performance. Such specialclients are those which have strategies that accept all offeredcommodities that are within specified basic constraints, if any. Amongsuch clients are those participants that have selected the previouslydescribed list completion strategy.

On the other hand, exchange definitions for more general clients areforwarded to e-agents, which perform the intermediated exchange forthese participants. Alternatively, all clients can be treated similarlywith their own e-agents, even such special, or list, clients.

FIGS. 7, 8, and 11 illustrate message flow internal to intermediary 3,between its principal functions, and also external to the intermediary,with its linked processes. These figures adopt the followingconventions. Messages exchanged between two components or processes inone direction are illustrated in one block of messages. The transmissiontime of each message in a block with respect to an intermediatedexchange is indicated by a parenthesized code that precedes the message.This code uses the following abbreviations: "B" denotes messages passedbefore commencement of an exchange; "M" denotes messages passed duringan exchange; "A" denotes messages passed after an exchange; "R1" denotesmessages for recovery of exchange failures; and "R2" denotes messagesfor recovery of reporting failures.

Now with respect to FIG. 11, the messages exchanged betweencommunications interface 112 of the intermediary 3 and connectedexternal processes are as follows. Before an intermediated exchange, theexchange driver 73 sends to the communications interface 112 messages ofthe types indicated in block 200, including: portfolio messages,extended data block messages, correction messages, and commands fromsystem operators. In more detail, portfolio messages include the list offinancial commodities, perhaps by trading symbol or CUSIP number, alongwith the maximum amounts to buy or sell. In addition, these messagesindicate certain parameterized constraints, such as minimum exchangeamount, cash imbalance, and tiering constraints. Such information,preferably packaged as a single message, is needed for all clients, butis adequate to completely describe only the limited clients which areprocessed in the previously described optimized fashion. For generalclients, extended data block messages are sent which include parameterssufficient to describe the general strategies and constraints accordingto, for example, the exemplary methods for counter-offer generationdescribed in Section 5.2.1. In a preferred implementation for generalclients, this extended information is packaged together with portfolioinformation in a single message. Alternatively, it can be packaged as aplurality of separate messages. The communications interface acceptscorrection messages, which correct or alter any exchange parameter forany client prior to commencement of an exchange. For general clients, itis preferred that a correction message replace all previously suppliedparameters with new parameters, whether or not changed. Finally,commands from system operators can query the state of intermediary 3 orinitiate an intermediated exchange. An exemplary exchange initiationcommand is represented by "Exchange|". The communications interfacefunction 112 returns validation and exchange result messages to theexchange driver 73, as indicated in block 201. Receipt of all the inputmessages is acknowledged in a validation message. Also, after completionof an intermediated exchange, communications interface function 112retrieves exchange results from the local data area and distributes themto the exchange driver 73 and tape reporting process 77. To the exchangedriver, the exchange results are distributed grouped by client orparticipant in a form adapted to further distribution to clients acrossthe client interface processes.

Just before commencement of an intermediated exchange, communicationsinterface function 112 requests the most current price data from tickerplant 101 for the commodities participating in the exchange and receivesthe prices in a message indicated in block 203. The identity ofparticipating commodities is determined by the allocation function 114,as is described subsequently. After completion of an exchange, thecommunications interface returns exchange results to the tape reportingservice 77 as indicated in block 202. The results are distributed as alist of exchanges by commodity in form adapted to the particularreporting service.

Finally, the communication interface sends to the database function 72,an exchange results message as indicated by block 205. These results aresent in a compact binary format for rapid storage. If recovery isneeded, processes restarted by the supervisor request check-pointedstate information sufficient to restart their processing. Messagescontaining this state information are indicated by the messages in block204. For example, to recover from failures after commencement but beforecompletion of an intermediated exchange, the communications interfaceretrieves all input data necessary to an exchange, such as copies ofportfolios, general client data blocks, corrections, and so forth. Whenthis data is restored, intermediary 3 waits for an operator command torestart an exchange. To recover from failures after a final exchange iscompleted, the compact binary form results of the just completedexchange are sent from the database 72 and report distribution restartedusing these retrieved results.

FIG. 7 illustrates the messages exchanged between each pair of principalinternal components of the intermediary 3 of FIG. 6. This figureillustrates an embodiment that is optimized to specially treat limited,or list, clients, which require one, or at most a small predeterminednumber of, rounds of negotiation according to the preferred protocol.Further, in a preferred object-based implementation, each message typeillustrated in FIG. 7 is sent by invoking methods in the object instancerepresenting the receiving function. Message types in block 130 are sentfrom the communications interface 112 to the local data area 113 at theindicated times. Thus, prior to an exchange, portfolio and constraintmessages, and corrections to these messages, for those limited clientswith the previously described optimized processing, are sent to thelocal data area. At the commencement of an exchange, the communicationsinterface also sends prices for the commodities to be exchanged to thelocal data area. Since the local data area preferably stores most shareddata needed by the intermediary, additional types of such data asrequired are forwarded from the communications interface for storage inthe local data area. Also, as indicated in block 130, for recovery ofthe failure of an exchange, the communications interface re-sends theseportfolio messages to the local data area, and for recovery of thefailure of reporting, the communications interface retrieves the resultsof the immediately previous exchange and sends them to the local dataarea 113. As indicated in message block 131, after an intermediatedexchange, the local data area 113 returns the results of the exchange tocommunications interface 112 for distribution.

The message types in block 134 are sent from the communicationsinterface 112 to the allocation function 114. Thus, prior to anexchange, and for recovery during exchange failure, the communicationsinterface 112 sends to the allocation function 114 those messagesdefining the exchange requirements and objectives of general clients.Such messages include at least extended data block messages and, also,portfolio messages, where several messages are used to define a generalclient. When the allocation function receives messages defining ageneral client portfolio, it starts an e-agent program of the processingtype defined by the model used by the client on the appropriate computerand the defining data is passed to it. For example, in the case offinancial commodities, it is preferred that the e-agent process offersaccording to mean-variance portfolio methods, as described in Section5.2.1. In this case, the information defining the e-agent can includeone or more of the variables listed in Table 3. Alternatively, thee-agent can process according to procedural rules, and the defininginformation is a representation of these rules. Additionally,communications interface 112 passes to allocation function 114 relevantoperator commands, such as the command Exchange| for initiating anintermediated exchange. Since shared data is preferably communicatedthrough the local data area 113, the allocation function returns nomessages directly to the communication interface. In an alternativeembodiment, the communications interface can communicate directly withthe e-agents, in which case it passes only commands directly to theallocation function.

Message types indicated in blocks 132 and 133, respectively, are sentbetween the allocation function and the local data area. Thus, at thecommencement of an intermediated exchange, the allocation function 114retrieves up-to-the-moment commodity price data from the local data area113, both for its use and for forwarding to the e-agents. The allocationfunction also fetches all data from the local data necessary for it tobuild an in-memory representation of its mathematical programmingproblem for offer generation. During the protocol of an intermediatedexchange, the local data area and allocation function exchange suchshared local data as is necessary for the computations performed by theallocation function's. Also portfolio and constraint data is provided tothe allocation function from the local data area for those limitedclients whose counter-offers are generated directly by the allocationfunction. Finally, when an exchange is completed, exchange results arereturned to the local data area for storage before further distribution.

FIG. 8 illustrates the messages exchanged between the e-agent 1 and theallocation function 114 of intermediary 3 across link 120. Message typesin block 135 are sent from the allocation function to the e-agent, andmessage types in block 136 are returned from the e-agent. In general, ane-agent responds to messages from the intermediary and does notindependently generating messages to an intermediary. E-agents respondto at least two general types of messages from the intermediary, queriesfor an initial e-agent opening message and queries for e-agentcounter-offer messages to previous intermediary offers. At thecommencement of an intermediated exchange, the intermediary queries thee-agents for their initial openings. In response, each e-agent specifiesthe maximum amount of each commodity that it is interested in buying orselling in this intermediated exchange. Optionally, an e-agent canpreserve the flexibility to be either a buyer or a seller of aparticular commodity, depending on the course of the intermediatedexchange, by specifying both a maximum amount to buy and a maximumamount to sell in the initial opening message. During the course of thepreferred protocol of an intermediated exchange, an e-agent responds toan offer from the intermediary with a counter-offer. The counter-offerspecifies the amounts of each commodity from the offer that the agent isinterested in buying or selling at this round of the negotiation. Ane-agent may not counter-offer to buy or sell more than the intermediaryoffered in the immediately preceding offer message. Optionally, thee-agent can simultaneously offer to buy and sell the same commodity. Theonly limitation on e-agent generation of counter-offers is given by thepreferred protocol for intermediated exchange as previously discussed.

In more detail, before an intermediated exchange, allocation function114 passes extended data blocks and other messages defining the exchangerequirements and objectives of a particular participant to theassociated e-agent. In an alternative implementation, the allocationfunction can also invoke e-agents for limited clients, such as for listclients. In this case, all client definitions and objectives arerepresented by appropriate e-agents and all portfolios, constraints, andobjectives are sent to e-agents. Also before an intermediated exchange,an e-agent can be tested by the intermediary sending one or more pairsof offers, followed by a query for the e-agent's counter-offer. Suchtesting can minimize the chances of admitting a failure-prone e-agent toan exchange.

Next, at the commencement of an intermediated exchange, the allocationfunction forwards up-to-the-moment price data to e-agents. Possibly inview of this price data, each e-agent determines the financialcommodities, described by symbols or CUSIP numbers, which it isinterested in trading in this exchange and sends this information to theintermediary. The intermediary then transmits to the e-agent thosecommodities that are to be actually exchanged in the current exchange,that is those commodities which have at least one e-agent interested inbuying and at least one other e-agent interested in selling. Thee-agents next transmit their opening messages, which are lists of thecommodities together with maximum amounts that the e-agent is interestedin exchanging. Alternatively, e-agents can transmit only openingmessages that have both commodities of interest and the upper bounds.

During the intermediated exchange, allocation function 114 and e-agents1 exchange offers and counter-offers according to the preferred protocolfor intermediated exchanges. Optionally, during an intermediatedexchange, an e-agent can transmit to the allocation function certaindata reflecting the process of its counter-offer generation, in orderthat its participant can be assured of its proper functioning andimprove future functioning. After an intermediated exchange completes,certain e-agents return an allocation message to allocation function114. Such e-agents represent participants that exchange multipleseparate portfolios, general or limited, according to the samerequirements and objectives. In this case, one e-agent performs theintermediated exchange for a portfolio combined from these multipleseparate portfolios, and on completion of the exchange, returns to theintermediary the allocation of its final accepted offer among themultiple separate portfolios which it is managing.

E-agents are implemented in a manner similar to that of theintermediary, and, especially, similar to that of the allocationfunction of the intermediary. Thus, preferably, e-agents are implementedwith an object-oriented methodology, for example in C++. They includemethods invoked by the allocation function for sending and receiving thedescribed messages. For financial commodities selected according tomean-variance portfolio methods, the e-agents preferably employcommercially available computational packages in a manner similar to theallocation function. These methods of such packages are capable ofsolving the constrained linear, quadratic, continuous, or mixed-integeroptimization problems in order to compute counter-offers. Further, theyconstruct in-memory representation of their mathematical programmingproblems in a manner similar to that of the intermediary.

Next, the processes which implement the message exchanges of anintermediated exchange are described in more detail, first with respectto the intermediary and second with respect to the e-agent. FIG. 9illustrates an embodiment of the process of the allocation function ofthe intermediary. In general, the allocation function waits at step 150for the "Exchange|" command before beginning an intermediated exchange.Next, at steps 151-154, it performs various initialization actions forthe intermediated exchange. At steps 155-158, the allocation functionperforms the intermediated exchange negotiation according to thepreferred protocol. Finally, at step 159 end-of-exchange post-processingis performed, and the allocation function returns to wait for anotherExchange| command.

In more detail, after receiving the Exchange| command, the intermediaryrequests up-to-the-moment asset prices and sends them to connectede-agents at step 151. The e-agents determine the financial commoditiesof interest for this exchange in view of these prices, and return a listof the commodities of interest upon query by the intermediary at step152. At step 153, the intermediary determines those commodities that canbe exchanged in this intermediated exchange and sends that list to theconnected e-agents. The commodities that can be exchanged are those forwhich at least one e-agent has indicated an interest in buying and atleast one other e-agent has indicated an interest in selling. Using thelist of commodities that can actually be exchanged, the allocationfunction and the e-agents update, respectively, their offer andcounter-offer computation methods to consider only those commoditiesthat can actually be exchanged. Thereby, commodities that are not to beexchanged are ignored in these computations, and computational demandsare decreased. Next at step 154, the exchange negotiation begins whenthe intermediary queries the e-agents for the commodities of interestalong with the maximum, and optionally minimum, amounts to be exchanged.Alternatively, these initialization steps can proceed in differentorders which have similar effects. For example, step 152 can be combinedwith step 154 so that the intermediary determines the commodities to beactually exchanged from the e-agents' opening messages. Also, theintermediary can delay making prices available to the e-agents untilafter receiving the e-agents' opening messages at step 154.

Next, at steps 155-158, the exchange negotiation is performed. At step155, the intermediary generates offers to all clients by, preferably,allocating the maximum amount of commodities for exchange in a fairmanner. For financial commodities, this is preferably performedaccording to the methods described in section 5.2.2. Offer determinationis optimized within the constraints on the amounts to be exchangedaccording to the current round of negotiation according to the preferredprotocol, together with any tiering, cash imbalance, or otherconstraints of the limited clients which are specially processed duringthe intermediary offer generation. During this optimization, offeramounts not meeting clients' minimum exchange requirements are set tozero, and the excess is reallocated optimally among the other clients.The commodity amounts in the computed offers are rounded to round-lots,and any rounding excess is fairly allocated among the e-agentsexchanging this commodity, according to the previously described method.At step 156, the generated and rounded offers are then sent to thee-agents representing general clients. Offers for limited clients, suchas list clients, can be automatically accepted by the intermediary,since they necessarily fall within the constraint bounds of theseclients, which, in fact, constrained the intermediary's offer generationat step 155. At step 157, the allocation function receives from thee-agents their counter-offer amounts selected from the preceding offeramounts. If all the counter-offer amounts equal the preceding offeramounts, test 159 terminates the intermediated exchange. If anycounter-offer amount does not equal its preceding offer amount, then theallocation function returned to step 155 to compute new offers for allthe clients.

After the intermediated exchange completes at step 158, step 159performs certain post-processing. First, those e-agents representingmultiple portfolios with identical requirements and objectives send tothe intermediary their allocations among their managed portfolios. Then,the allocation function sends to the local data area the intermediatedexchange results in the format of one binary data block. As described,the communication interface function then distributes these exchangeresults to the individual clients, to the tape reporting service, toadministrative systems, and to the database. The allocation functionthen returns to step 150 to wait for a command signalling commencementof the next intermediated exchange.

FIG. 10 illustrates a process for the e-agents of this invention.Preferably, in general, an e-agent is a slave of the intermediary,waiting for messages from the intermediary and responding appropriatelyto each received message. Therefore, at step 170, an e-agent waits forand reads the next message from the intermediary. At steps 171, 173,175, 177, 179, and 181 the e-agent tests a received message for thevarious recognized message types, and performs processing appropriate toeach recognized message type. If an unrecognized message type isreceived, step 183 indicates this error and performs appropriateprocessing, which optionally can include causing this intermediatedexchange to fail and exchange recovery to be entered.

Turning now to the detailed message types recognized, if an e-agentreceives a query assets message, at step 172 it returns a message to theintermediary with a list of the commodities of interest in thisexchange. When an e-agent receives a prices message from theintermediary, at step 174 it computes the maximum and minimum amounts ofeach commodity that it is interested in trading in this exchange. Whenan e-agent receives a "send commodity" message, at step 176 it updatesits counter-offer computation methods with the commodities to beactually exchanged. Thereby, commodities in which it was interested butwhich are not to be exchanged are not considered in future computations.This increases the efficiency of e-agent counter-offer computation. Whenan e-agent receives a query opening message, at step 178 it sends theopening message of the preferred negotiation protocol described above.This message includes the assets of interest together with their maximumand minimum amounts, these limits having been computed at step 174.Steps 171-178 perform e-agent initialization for this particularintermediated exchange. As described for the intermediary, these stepsmay be altered or combined in various fashions corresponding withsimilar alternatives for the intermediary. Finally, when an e-agentreceives an offer message, at step 180 it computes its selection, whichis preferably optimized, from the commodity amounts offered, which itreturns when queried. When an e-agent receives a query counter-offermessage, at step 182 it returns to the intermediary thesecounter-offered commodity amounts.

Preliminary to the process illustrated in FIG. 10, the e-agent has beeninvoked and provided with the extended data and, optionally, portfoliodata, necessary to define the detailed processing in the illustratedsteps.

Programs for the intermediary and the e-agent, both in a human readableform and a machine readable form capable of causing a computer toexecute these programs, can be recorded on any convenient computerreadable medium. Such mediums include magnetic discs, both hard discsand floppy discs, on optical discs, such as CD-ROM discs, on magnetictape, and so forth.

6. SPECIFIC EMBODIMENTS, CITATION OF REFERENCES

The present invention is not to be limited in scope by the specificembodiments described herein. Indeed, various modifications of theinvention in addition to those described herein will become apparent tothose skilled in the art from the foregoing description and accompanyingfigures. Such modifications are intended to fall within the scope of theappended claims.

Various publications are cited herein, the disclosures of which areincorporated by reference in their entireties.

What is claimed is:
 1. A computer system for electronic intermediatedexchange of a plurality of commodities among a plurality of participantscomprising:a. one or more computer-based machines; b. a plurality ofelectronic agent (e-agent) computer programs running on at least one ofsaid computer-based machines, wherein each said participant isassociated with at least one of said e-agent computer programs, and eachsaid e-agent computer program stores in an electronic memory digitaldata representing commodity exchange objectives of its associatedparticipant; and c. an electronic intermediary computer program runningon at least one of said computer-based machines, wherein saidintermediary computer program stores in an associated electronic memorydigital data representing commodity exchange objectives of theintermediated exchange and exchanges electronic offer and electroniccounter-offer messages with said e-agent computer programs; wherein (i)said e-agent computer programs receive said electronic offer messagesfrom said intermediary computer program, generate said electroniccounter-offer messages according to said exchange objectives of saidassociated participants, and send said electronic counter-offer messagesto said intermediary computer program, and (ii) said intermediarycomputer program receives said electronic counter-offer messages fromsaid e-agent computer programs, generates said electronic offer messagesaccording to said exchange objectives of said intermediated exchange,and sends said electronic offer messages to said e-agent computerprograms.
 2. The computer system of claim 1 wherein said commodities areintangible commodities.
 3. The computer system of claim 1 wherein saidexchange of electronic messages between said intermediary computerprogram and said e-agent computer programs converges to an exchange ofsaid commodities, that is substantially satisfactory both to saide-agent computer programs, according to said digital data representingsaid commodity exchange objectives of said participants, and also to theintermediary computer program, according to said digital datarepresenting commodity exchange objectives of the intermediatedexchange.
 4. The computer system of claim 1 wherein said electronicoffer messages contain digital data representing the amounts of saidcommodities that said intermediary computer program offers to saide-agent computer programs, and wherein said electronic counter-offermessages contain digital data representing the amounts of saidcommodities that said e-agent computer programs accept from saidintermediary computer program.
 5. The computer system of claim 4 whereinsaid exchange of electronic messages terminates when said e-agentcomputer programs generate electronic counter-offer messages acceptingall the amounts of commodities offered in the immediately precedingelectronic offer messages received from said intermediary computerprogram.
 6. The computer system of claim 4 wherein said e-agent computerprograms generate electronic counter-offer messages accepting amounts ofcommodities that are less than or equal to the amounts offered in one ormore of the preceding electronic offer messages received from saidintermediary computer program.
 7. The computer system of claim 6 whereinsaid one or more preceding intermediary computer program electronicoffer messages is the immediately preceding electronic offer message. 8.The computer system of claim 4 wherein the e-agent computer programs andthe intermediary computer program exchange messages according tosequential rounds of an electronic negotiation, each round of saidnegotiation comprising said intermediary computer program sendingelectronic offer messages to said e-agent computer programs followed bysaid e-agent computer programs sending electronic counter-offer messagesto said intermediary computer program.
 9. The computer system of claim 8wherein said electronic memory associated with said intermediarycomputer program further stores digital data representing a plurality ofcurrent and preceding bounds, each said current bound representing themaximum amount of a particular commodity that can be offered to aparticular e-agent computer program in a current round of saidelectronic negotiation and each said preceding bound being a currentbound from a preceding round of said electronic negotiation, and whereinsaid intermediary computer program generates electronic offer messagesoffering amounts of commodities less than or equal to the appropriateone of said current bounds.
 10. The computer system of claim 9 whereinsaid plurality of current bounds depends at least on commodity amountsin said intermediary electronic offer messages, said e-agent electroniccounter-offer messages, and said preceding bounds from one or morepreceding rounds of said electronic negotiation.
 11. The computer systemof claim 10 wherein said one or more preceding rounds of said electronicnegotiation is the immediately preceding round of said electronicnegotiation.
 12. The computer system of claim 9 wherein said pluralityof current bounds depends at least on commodity amounts in said e-agentelectronic counter-offer messages and on the preceding bounds from theimmediately preceding round of said electronic negotiation.
 13. Thecomputer system of claim 12 wherein said electronic memory associatedwith said intermediary computer program further stores digital datarepresenting a selected round of said electronic negotiation, whereinbefore said selected round of negotiation said plurality of currentbounds are selected to be between commodity amounts in said e-agentelectronic counter-offer messages and said preceding bounds of theimmediately preceding round of said electronic negotiation, and whereinafter said selected round of negotiation the plurality of current boundsare selected to be equal to e-agent electronic counter-offer messages ofthe immediately preceding round of said electronic negotiation.
 14. Thecomputer system of claim 13 wherein before said selected round ofnegotiation said plurality of current bounds are selected to besubstantially a weighted average of the commodity amounts in saide-agent electronic counter-offer messages and said preceding bounds ofthe immediately preceding round of said electronic negotiation.
 15. Thecomputer system of claim 1 wherein said e-agent computer programsfurther send electronic opening messages to said intermediary computerprogram before said exchange of electronic offer and counter-offermessages, each said electronic opening message including digital datarepresenting maximum amounts of commodities each participant willexchange in said intermediated exchange.
 16. The computer system ofclaim 1 wherein said electronic memory associated with said intermediarycomputer program further stores digital data representing a plurality ofbounds on selling or buying of each commodity by each e-agent computerprogram, and wherein said commodity exchange objectives of saidintermediary computer program comprise that a substantially maximizedamount of commodities are exchanged in said intermediated exchangesubject to constraints (i) that for each said commodity the total amountsold equals the total amount bought by all said e-agent computerprograms, and (ii) that for each commodity the amount sold or bought byeach e-agent computer program is less than the appropriate one of saidbounds.
 17. The computer system of claim 16 wherein said commodityexchange objectives of said intermediary computer program furthercomprise that a measure of the unfairness of the share of commoditiesoffered to each e-agent computer program is substantially minimized. 18.The computer system of claim 17 wherein said measure of unfairnessincreases substantially as the share of commodities offered to eache-agent computer program differs from a pro-rata share.
 19. The computersystem of claim 18 wherein said measure of unfairness increasessubstantially as the square of the difference of the share ofcommodities offered to each e-agent computer program differs from apro-rata share.
 20. The computer system of claim 18 wherein saidpro-rata share for a commodity for an e-agent computer program dependsat least on the ratio of said bounds for that commodity for that e-agentcomputer program to the sum of the bounds for that commodity for all thee-agent computer programs.
 21. The computer system of claim 18 whereinsaid measure of unfairness includes a plurality of adjustable factors,each factor associated with an e-agent computer program and foradjusting the rate of increase of said measure of unfairness as theshare of commodities offered to an e-agent computer program differs froma pro-rata share.
 22. The computer system of claim 1 wherein saidelectronic offer messages contain digital data representing the amountsof commodities offered to said e-agent computer programs, and whereinsaid intermediary computer program generates said commodity amounts forsaid electronic offer messages by substantially maximizing the value ofa utility function of said amounts of commodities subject to e-agentsconstraints.
 23. The computer system of claim 22 wherein said utilityfunction comprises a difference of a first terms and a second term, saidfirst term representing the total amount of all commodities offered tosaid e-agent computer programs and said second term representing theunfairness of the share of commodities offered to said e-agent computerprograms.
 24. The computer system of claim 22 wherein one or morenon-linear terms in said utility function is approximated by a pluralityof piece-wise linear terms.
 25. The computer system of claim 22 whereinsaid commodities are exchanged in whole commercial units, and whereinany fractional commercial units generated by substantially maximizingthe value of said utility function are reallocated among said e-agentcomputer programs in a substantially fair manner, whereby only wholecommercial units of commodities are actually offered.
 26. The computersystem of claim 1 wherein said electronic counter-offer messages containdigital data representing the amounts of said commodities that saide-agent computer programs accept from said intermediary computerprogram, and wherein at least one of said e-agent computer programsgenerates electronic counter-offer messages by accepting all commodityamounts previously offered by said intermediary computer program andlimited by pre-specified maximum commodity exchange bounds and byoptional constraints.
 27. The computer system of claim 1 wherein saidelectronic counter-offer messages contain digital data representing theamounts of said commodities that said e-agent computer programs acceptfrom said intermediary computer program, and wherein at least one ofsaid e-agent computer programs generates electronic counter-offermessages by executing a computer program that substantially maximizesthe value of a utility function of said commodity amounts.
 28. Thecomputer system of claim 27 wherein said utility function is determinedaccording to mean-variance portfolio methods.
 29. The computer system ofclaim 28 wherein said utility function comprises a difference of twoterms, a first term representing the expected return from a portfoliohaving said commodity amounts and a second term representing the risk ofa portfolio having said commodity amounts.
 30. The computer system ofclaim 27 wherein said maximization of said utility function is limitedby optional constraints.
 31. The computer system of claim 1 wherein saidelectronic counter-offer messages contain digital data representing theamounts of said commodities that said e-agent computer programs acceptfrom said intermediary computer program, and wherein at least one ofsaid e-agent computer programs for said associated participant generateselectronic counter-offer messages by executing procedural rules havingvariables referring to said commodity amounts.
 32. The computer systemof claim 1 wherein at least one of said e-agent computer programs isprovided by said associated participant.
 33. The computer system ofclaim 1 wherein at least one of said e-agent computer programs ismemoryless.
 34. The computer system of claim 1 wherein at least one ofsaid participants is associated with more than one e-agent computerprograms.
 35. The computer system of claim 1 wherein at least one ofsaid e-agent computer programs is an autonomously running computerprocess.
 36. The computer system of claim 1 wherein at least one of saide-agent computer programs are executed on the same computer-basedmachine as said intermediary computer program.
 37. The computer systemof claim 1 wherein at least one of said e-agent computer programs areexecuted on a computer-based machine geographically remote from thecomputer-based machine on which said intermediary computer program isexecuted.
 38. The computer system of claim 1 further comprisingcommunications means for sending digital information representing saidelectronic offer messages and said electronic counter-offer messagesbetween said e-agent computer programs and said intermediary computerprogram.
 39. The computer system of claim 38 wherein said communicationmeans includes means functioning according to the IP or the TCP/IPcommunication protocols.
 40. The computer system of claim 38 whereinsaid communication means includes inter-process communication means ofan operating system of one of said computer-based machines running atleast one of said e-agent computer programs and said intermediarycomputer program.
 41. The computer system of claim 38 wherein saidcommunication means includes inter-computer communication means betweenat least two of said computer-based machines where said e-agent computerprograms and said intermediary computer programs are executed.
 42. Thecomputer system of claim 1 wherein said e-agent computer programsreceive electronic order messages from computers of said associatedparticipants, said electronic order messages containing digital datarepresenting said commodity exchange objectives of said associatedparticipants, and wherein said intermediary computer program sendselectronic results messages to said computers of said participants, saidelectronic results messages containing digital data representing theresults of an intermediated exchange.
 43. The computer system of claim42 wherein said digital data representing said commodity exchangeobjectives of said participants is tested before said electronicintermediated exchange begins.
 44. The computer system of claim 1further comprising a supervisor computer program running on at least oneof said computer-based machines, and wherein said supervisorperiodically tests each computer program of said computer computersystem to determine if it has failed.
 45. A computer implemented methodfor an electronic intermediated exchange of a plurality of commoditiesamong a plurality of participants comprising the electronic negotiationsteps of:a. sending a plurality of electronic offer messages generatedby an intermediary computer program to a plurality of e-agent computerprograms, each e-agent computer program associated with and representingone of said participants, each said electronic offer message includingdigital data representing amounts of commodities offered to said e-agentcomputer programs by said intermediary computer program; b. sending aplurality of electronic counter-offer messages generated by said e-agentcomputer programs to said intermediary computer program, each saidelectronic counter-offer message including digital data representingamounts of commodities accepted by said e-agent computer program; and c.repeating steps (a) and (b) until the amounts of commodities in saidelectronic offer messages are substantially satisfactory to said e-agentcomputer programs, according to exchange objectives of said participantsstored as digital data accessible to said e-agent computer programs, andto said intermediary computer program, according to objectives for saidintermediated exchange stored as digital data accessible to saidintermediary computer program.
 46. The method of claim 45 wherein saidelectronic counter-offer messages generated by said e-agent computerprograms represent accepted amounts of commodities that are less than orequal to amounts of commodities represented in one or more of saidpreceding electronic offer messages received from said intermediarycomputer program.
 47. The method of claim 46 wherein said one or morepreceding electronic offer messages is the immediately precedingelectronic offer message.
 48. The method of claim 45 wherein step (c)terminates when said e-agent computer programs generate electroniccounter-offer messages representing acceptance of the total amounts ofcommodities offered in the immediately preceding electronic offermessages received from said intermediary computer program.
 49. Themethod of claim 45 wherein step (a) further comprises said intermediarycomputer program, first, determining digital data representing aplurality of bounds, each said bound representing a maximum amount of aparticular commodity that can be offered to a particular e-agentcomputer program in a current round of said electronic negotiation, andsecond, generating said electronic offer messages representing offeredamounts of commodities less than or equal to the appropriate one of saidbounds.
 50. The method of claim 49 further comprising before step (a) astep of sending a plurality of electronic opening messages from saide-agent computer programs to said intermediary computer program, eachsaid electronic opening message including digital data representingmaximum amounts of commodities participants will exchange in saidintermediated exchange, and wherein said intermediary determines saidbounds initially to be said maximum amounts.
 51. The method of claim 49wherein said bounds in a later round of said negotiation are not greaterthan said bounds in an earlier round of said negotiation.
 52. The methodof claim 49 wherein said plurality of bounds in a current round of saidnegotiation depends on commodity amounts represented in saidintermediary electronic offer messages, said e-agent electroniccounter-offer messages, and said bounds from one or more precedingrounds of said negotiation.
 53. The method of claim 52 wherein said oneor more preceding rounds of said negotiation is the immediatelypreceding round of said negotiation.
 54. The method of claim 49 whereinsaid plurality of current bounds depends at least on commodity amountsrepresented in said e-agent electronic counter-offer messages and onsaid bounds from the immediately preceding round of said negotiation.55. The method of claim 54 wherein said plurality of bounds depends atleast on a weighted average of commodity amounts represented in saide-agent electronic counter-offer messages and said bounds from theimmediately preceding round of said negotiation.
 56. The method of claim55 wherein after a selected round of said negotiation said bounds aredetermined to be equal to commodity amounts represented in said e-agentelectronic counter-offer messages from the immediately preceding roundof said negotiation.
 57. The method of claim 45 further comprisingbefore step (a) a step of sending from said intermediary computerprogram to said e-agent computer programs a plurality of electronicinitial messages, each said electronic initial message including digitaldata representing the particular commodities that can be exchanged insaid intermediated exchange.
 58. The method of claim 45 furthercomprising before step (a) a step of said e-agent computer programsreceiving and storing a plurality of electronic order messages from saidparticipants, each said electronic order message including digital datarepresenting said exchange objectives of that participant.
 59. Themethod of claim 45 further comprising after step (c) a step of sending aplurality of electronic results messages to each said participant, eachsaid electronic results message including digital data representing theamounts of commodities in said satisfactory electronic offer message.60. The method of claim 45 further comprising before step (a) a step ofsaid intermediary computer program receiving and storing electronicobjective messages from an operator of said electronic intermediatedexchange, each said electronic objective message including digital datarepresenting said objectives of said intermediated exchange.
 61. Acomputer readable medium comprising encoded instructions for causing anelectronic computer to function according to claim
 45. 62. A computerimplement method for representing a participant in an intermediatedexchange of commodities, said intermediated exchange performed by anelectronic negotiation with an intermediary computer program, saidmethod comprising:a. receiving an electronic order message from acomputer of said participant, said electronic order message includingdigital data representing the objectives of said participant for saidintermediated exchange in order that e-agent computer program canrepresent said participant; b. receiving one of a plurality ofelectronic request messages from said intermediary computer program; andc. sending one of a plurality of electronic response messages to saidintermediary computer program in response to said electronic requestmessage, said electronic response message being(i) an electronic openingmessage, if said electronic request message was a query for anelectronic opening message, said electronic opening message includingdigital data representing the maximum amounts of commodities that saide-agent computer program will exchange in said intermediated exchange,and (ii) an electronic counter-offer message, if said electronic requestmessage was an electronic offer message, said electronic offer messageincluding digital data representing amounts of commodities offered tosaid e-agent computer program by said intermediary computer program,said electronic counter-offer message including digital datarepresenting amounts of commodities accepted by said e-agent computerprogram as determined according to exchange objectives, said acceptedamounts being less than or equal to said offered amounts and being allequal to said offered amounts only if said offered amounts meet saidexchange objectives.
 63. The method of claim 62 further comprising,between steps (a) and (b), a step of exchanging one or more electronicinitial messages between said e-agent computer program and saidintermediary computer program, said electronic initial messagesincluding digital data representing commodities of interest to saidparticipant according to said exchange objectives as determined by saide-agent computer program, and commodities participating in saidintermediated exchange with prices for said participating commodities asdetermined by said intermediary computer program.
 64. The method ofclaim 62 wherein said exchange objectives are expressed as proceduralrules which determine accepted amounts of commodities from offeredamounts of commodities.
 65. The method of claim 62 wherein said exchangeobjectives are expressed according to mean-variance portfolio theory.66. The method of claim 65 wherein said exchange objectives areexpressed as utility function of commodity amounts, and wherein acceptedcommodity amounts substantially maximize said utility function subjectto maximum amount constraints given by said offered commodity amounts.67. The method of claim 66 wherein said utility function includes termsrepresenting expected return and expected risk.
 68. A computer readablemedium comprising encoded instructions for causing an electroniccomputer to function according to claim
 62. 69. A computer implementedmethod for an intermediated exchange of commodities among a plurality ofparticipants, each participant represented by an e-agent computerprogram, said method comprising:a. sending electronic opening messagesto an intermediary computer program from said e-agent computer programs,said electronic opening messages including digital data representing themaximum amount of each commodity that each e-agent computer program willexchange in said intermediated exchange; b. sending electronic offermessages by said intermediary computer program to said e-agent computerprograms, each said electronic offer message including digital datarepresenting amounts of commodities currently offered to each e-agentcomputer program, said amounts being determined so that for eachcommodity the amount being offered for sale by all the e-agent computerprograms equals the amount being offered for purchase by all the e-agentcomputer programs; c. receiving electronic counter-offer messages bysaid intermediary computer program from said e-agent computer programs,each said electronic counter-offer message including digital datarepresenting amounts of offered commodities accepted by each saide-agent computer program, said accepted commodity amounts being lessthan or equal to said offered commodity amounts; d. repeating steps (b)and (c), each repetition being a round of an electronic negotiation,until said e-agent computer programs accept all the amounts ofcommodities offered, said accepted amounts being final commodityamounts; and e. sending results electronic messages to computers of saidparticipants, said electronic results messages including digital datarepresenting said final commodity amounts.
 70. The method of claim 69further comprising before step (a), a step of exchanging one or moreelectronic initial messages between said intermediary computer programsand said e-agent computer programs, said electronic initial messagesincluding digital data representing commodities that said e-agentcomputer programs will exchange in said intermediated exchange, andcommodities actually participating in said intermediated exchange withprices for said participating commodities.
 71. The method of claim 69wherein step (b) further comprises said intermediary computer program,first, determining digital data representing a plurality of bounds, eachsaid bound representing a maximum amount of a particular commodity thatcan be offered to a particular e-agent computer program in a currentround of said electronic negotiation, and second, generating saidelectronic offer messages representing offered amounts of commoditiesthat are less than or equal to said bounds.
 72. The method of claim 71wherein said intermediary computer program determines said boundsinitially to be said maximum amounts.
 73. The method of claim 71 whereinsaid bounds in a later round of said negotiation are not greater thancorresponding bounds in an earlier round of said negotiation.
 74. Themethod of claim 71 wherein said plurality of bounds in a current roundof said negotiation depends at least on commodity amounts represented insaid intermediary electronic offer messages, said e-agent electroniccounter-offer messages, and said bounds from one or more precedingrounds of said negotiation.
 75. The method of claim 74 wherein said oneor more preceding rounds of said negotiation is the immediatelypreceding round of said negotiation.
 76. The method of claim 71 whereinsaid plurality of current bounds depends at least on commodity amountsrepresented in said e-agent electronic counter-offer messages and onsaid bounds from the immediately preceding round of said negotiation.77. The method of claim 76 wherein said plurality of bounds depends atleast on a weighted average of commodity amounts represented in saide-agent electronic counter-offer messages and said bounds from theimmediately preceding round of said negotiation.
 78. The method of claim77 wherein after a selected round of said negotiation said bounds aredetermined to be equal to commodity amounts represented in said e-agentelectronic counter-offer messages from the immediately preceding roundof said negotiation.
 79. The method of claim 69 further comprisingbefore step (a) a step of sending from said intermediary computerprogram to said e-agent computer programs a plurality of electroniccommodity messages, each said electronic commodity message includingdigital data representing the particular commodities that can beexchanged in said intermediated exchange.
 80. A computer readable mediumcomprising encoded instructions for causing an electronic computer tofunction according to claim
 69. 81. An order-manager computer system forelectronic intermediated exchange of a plurality of commodities among aplurality of participants, said computer system comprising:a. one ormore computer-based machines; b. a plurality of client-interfaceelectronic processes running on one or more of said computer-basedmachines for communicating with computer-based machines of saidparticipants in order to receive from said participants electronic ordermessages representing exchange objectives of said participants and tosend to said participants electronic results messages representing thecommodities exchanged in said intermediated exchange; c. anexchange-driver electronic process running on one of said computer-basedmachines for transferring said electronic order messages and saidelectronic results messages between said client-interface processes andan intermediary electronic process; d. an electronic database running onone of said computer-based machines for storing copies of said order andsaid electronic results messages, and, in event of process failure insaid order-manager computer system, for retrieving said message copiesin order to restart said failed process; and e. a plurality of e-agentelectronic processes running on one or more of said computer-basedmachines, each said e-agent process for representing one of saidparticipants according to said exchange objectives by generatingelectronic counter-offer messages sent to said intermediary process inresponse to electronic offer messages received from said intermediaryprocess; wherein f. said intermediary electronic process running on oneof said computer-based machines for generating said electronic offermessages sent to said e-agent processes in response to said electroniccounter-offer messages received from said e-agent processes, saidexchange of offer and electronic counter-offer messages being accordingto a protocol for performing said intermediated exchange, and furtherfor generating said electronic results messages when said intermediatedexchange completes.
 82. The order-manager computer system of claim 81further comprising communication means interconnection saidcomputer-based machines.
 83. The order-manager computer system of claim81 wherein said electronic offer messages and said electroniccounter-offer messages include digital data representing amounts ofcommodities, and wherein according to said protocol (i) the amounts ofcommodities represented in said electronic counter-offer messages areless than or equal to the amounts of commodities represented inimmediately preceding corresponding electronic offer messages, and (ii)the amounts of commodities represented in said electronic offer messagesare less than or equal to the amounts of commodities represented inimmediately preceding corresponding electronic offer messages.
 84. Theorder-manager computer system of claim 81 wherein said intermediaryprocess further comprises:a. a communications interface component forcommunicating messages between the intermediary process and the exchangedriver process and the database; b. an allocation component forperforming the computations for generating said electronic offermessages; and c. a local data area component for storing data to beexchanged between said communication interface component and saidallocation component.
 85. The order-manager computer system of claim 81further comprising:a. a supervisor process running on one of saidcomputer-based machines for periodically testing other processes of saidorder-manager computer system for failure, and in case of failure, formanaging restart of any failed process detected by the supervisorprocess; and b. a slave-supervisor process running on one of saidcomputer-based machines for periodically testing said supervisor processfor failure, and in case of failure, for assuming the functions of saidsupervisor process.